쿠키와 세션은 왜 등장했을까 ?
HTTP 통신은 요청(Request) -> 응답(Response) 이 종료되면 stateless(상태가 유지되지 않은) 한 특징 때문에 연결을 끊는 처리 방식입니다.
로그인과 같은 일을 할 때, '누가' 로그인 중인지 상태를 기억하기 위해 쿠키, 세션, 토큰을 사용합니다.
- Connectionless 프로토콜(비연결 지향)
클라이언트가 서버에 요청을 했을 때, 요청에 맞는 응답을 보낸 후 연결을 끊는 처리방식이다. - Stateless 프로토콜(상태정보 유지 안함)
클라이언트의 상태 정보를 가지지않는 서버 처리 방식이다. 클라이언트와 첫번재 통신에 데이터를 주고 받았다 해도, 두버재 통신에 이전 데이터를 유지하지않는다.
🍪 쿠키
쿠키는 공개 가능한 정보를 사용자의 브라우저에 저장시킨다. (그렇다고 털려도 된다는 소리는 x)
- 서버는 클라이언트의 로그인 요청에 대한 응답을 작성할 때, 클라이언트 측에 저장하고 싶은 정보를 응답 헤더의
set-cookie에 담는다. - 이후 클라이언트가 재요청 할 때마다 저장된 쿠키를 요청 헤더의
cookie에 담아 보낸다. - 서버는 쿠키에 담긴 정보를 바탕으로 해당 요청의 클라이언트가 누군지 식별 할 수 있다.
🔒 세션
예를들어 사용자의 로그인 상태를 유지하는 기능을 위해 쿠키에 아이디와 비밀번호를 담아두고 있습니다. 이렇게 된다면 개인 소유가 아닌 컴퓨터에서 사용할 경우 사용자의 개인정보가 털릴것이고, http로 개인정보를 주고 받다보면 쿠키가 유출, 조작이 될 수 있는 보안상 큰 문제를 야기시킵니다.
session은 비밀번호와 같은 인증 정보를 쿠키에 저장하지 않고 대신에 사용자의 식별자인 session id 를 저장합니다. 서버에는 인증 정보와 더불어 이 ID에 해당하는 사용자의 정보를 저장합니다.
세션은 서버에 저장하기 때문에 사용자가 수백, 수천, 수만으로 늘어난다면 해당 유저의 정보를 찾고 데이터 매칭에 오랜 시간이 걸리면서 서버에 부하가 가해지게 됩니다.
💰 토큰(JWT)
Authentication : 인증. 내가 누구인지 증명 ! 해주는 것.
Authorization : 인가. 음.. 너구나 ! ok 통과다
단순 웹 토큰(SWT) 및 SAML(Security Assertion Markup Language) 토큰과 비교할 때 JWT 를 사용하면 이점이 있습니다. 쿠키와과 세션을 동시에 사용하는 인증 방식이라고도 이해하고있습니다
1. More Compact : JSON으로 인코딩 하기 때문에, XML로 인코딩하는 SAML 토큰보다 작습니다.
2. More Secure : JWT는 공개키와 개인키를 나누어 서명이 가능합니다. HMAC 암호 알고리즘을 사용하여 암호화된 서정도 가능합니다.
3. More Common : JSON의 object는 일반적인 프로그래밍 언어이기때문에 접근성이 좋습니다.
4. Easier to process : JWT는 인터넷 규모로 사용됩니다. 모바일에서 처리하는 것이 더 쉽다는 것을 의미합니다.
토큰의 구조
토큰은 헤더(Header),페이로드(payload),서명(signature) 세 파트를 . 으로 구분하는 구조입니다.
Header
JWT를 검증하는데 필요한 정보를 가진 JSON 객체는 Base64 URL-Safe 인코딩된 문자열입니다. 헤더는 jwt를 어떻게 검증(verify)하는가에 대한 내용을 담고 있습니다. alg는 서명시 사용하는 알고리즘이고, kid는 서명시 사용하는 키(pubilc/private key)를 식별하는 값입니다.
Payload
JWT의 내용입니다. 페이로드에 있는 속성들을 클레임 셋(Claim Set)이라고 부릅니다. 클레임 셋은 jwt에 대한 내용(토큰 생성자의 정보, 생성일시,,,)이나 클라이언트와 서버 간 주고받기로 한 데이터들로 구성됩니다.
Signature
점(.)을 구분자로 해서 헤더와 페이로드를 합진 문자열을 서명한 값입니다. 서명은 헤더의 alg에 정의된 알고리즘과 비밀 키를 이용해 생성하고 Base64 URL-Safe로 인코딩 합니다.
장점
- header와 payload 를 가지고 signaure를 생성하므로 데이터 위변조를 막을 수 있다.
- 인증 정보에 대한 별도의 저장소가 필요없다. (서버 부하 ↓)
- JWT는 토큰에 대한 기본 정보과 전달할 정보 및 토큰이 검증 되었다는 서명 등 필요한 모든 정보를 자체적으로 지니고 있다.
- 토큰은 한 번 발급되면 유효기간이 만료될 때까지 계속 사용이 가능하다.
단점
- 쿠키나 세션과 다르게 JWT는 토큰의 길이가 길어 인증 요청이 많아질수록 네트워크 부하가 심해진다.
- payload 자제는 암호화되지 않기 땨문에 유저의 중요한 정보를 담으면 안된다.
- 토큰을 탈취당하면 대처하기 어렵다.
- 특정 사용자의 접속을 강제로 만료하기 어렵지만, 쿠키/세션 기반 인증은 서버 쪽에서 쉽게 세션을 삭제 할 수 있다.
🔑 보안 전략
1. 짧은 만료 기한 설정
토큰의 만료 시간이 짧으면 탈취되더라도 금방 만료되기 때문에 피해를 최소화 할 수 있습니다. 하지만 사용자가 자주 로그인 해야하는 불편함이 있습니다.
2. Sliding Session
예를들어 로그인하고 글을 작성하는 도중 토큰이 만료 된다면 저장 작업이 정상적으로 작동하지않고 작성한 글이 날아가는 일이 생기는 등 불편함이 존재합니다. Sliding Session은 서비스를 지속적으로 이용하는 클라이언트에게 자동으로 토큰 만료 기한을 늘려주는 방법입니다. 1번의 자주 로그인해야하는 단점을 보완시켜줍니다.
3. Refresh Token
클라이언트가 로그인 요청을 보내면 서버는 Access Token과 그보다 만료기간이 긴 Refresh Token을 함께 내려줍니다. 클라이언트는 Access Token이 만료되었을 때, Refresh Token을 사용하여 Acess Token의 재발급을 요청합니다. 서버는 DB에 저장된 Refresh Token과 비교하여 유요한 경우 새로운 Access Token을 발급하고, 만료된 경우 다시 로그인 시킵니다.
검증을 위해서는 서버에 Refresh Token을 별도로 저장시켜야합니다.
📄 도움받은글
