Cookie, Session과 Token

보통 SSR (Server Side Rendering) 방식으로 프로젝트를 구성했기 때문에 Cookie와 Session을 통한 로그인으로

인증 인가를 구성했는데 이번에 Rest API를 이용하여 프로젝트를 구성하다 보니 Token 기반의 로그인을
구성하게 되었다.

이번 시간에는 Cookie, Session, Token에 대하여 헷갈리지 않도록 확실하게 짚고 넘어가려고 한다.

---

🍪 쿠키란 무엇인가

쿠키란 사용자를 기억하기 위해 서버가 사용자의 브라우저에 저장하는 데이터라고 할 수 있다.

 

쿠키의 동작 방식

1. 서버는 클라이언트의 로그인 요청에 대한 응답을 작성할 때,
   클라이언트 측에 저장하고 싶은 정보를 응답 헤더의 set-cookie에 담는다.
2. 클라이언트가 재요청을 할 때마다 저장된 쿠키를 요청 헤더의 cookie에 담아 보낸다.
3. 서버는 쿠키에 담긴 정보를 바탕으로 해당 요청의 클라이언트를 식별한다.

 

쿠키의 단점

1. 보안에 취약하다. (정보 요청 시 쿠키를 그대로 보내기 때문에 유출 및 조작 위험성이 존재한다.)
2. 용량 제한이 있다.
3. 브라우저 간 공유가 불가능하다.
4. 쿠키 사이즈가 커질 수록 부하가 생긴다.

---

🔒 Session이란 무엇인가

Session은 클라이언트의 민감한 정보를 브라우저가 아닌 Server에서 저장하고 관리하는데
이때 사용자 식별을 위한 session Id를 부여한다.

 

Session의 동작 방식

1. 사용자가 로그인 시 세션이 서버에 저장한다.
2. 서버가 브라우저 쿠키에 session Id를 저장한다.
3. 해당 사이트의 모든 request에 session Id 쿠키에 담아 전송한다.
4. 서버는 해당 session Id를 관리하고 있는 session Id와 비교하여 인증한다.

 

Session의 단점

1. 사용자가 많을 경우 로드 밸런싱을 통한 서버 확장을 이용하는데 이때 관리가 어렵다.
2. session은 서버에서 관리하기 때문에 서버 부담이 심하다.
3. 보통 쿠키와 함께 사용하는데 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 되어 있어
   CORS의 경우 쿠키 및 세션 관리가 힘들다.

---

 📀 Token이란 무엇인가

 

Token이란 서버가 각 클라이언트를 구별할 수 있도록 유니크한 정보를 담은 암호화 데이터이다.

위에서 설명한 Session의 경우처럼 stateful하면 서버의 부담이 커지기 때문에

상태를 유지하지 않는 stateless한 token 방식이 생겨났다.

 

Token의 동작 방식

1. 사용자가 로그인 시 서버는 사용자에게 유일한 토큰을 발급한다.
2. 사용자는 전달받은 토큰을 어딘가에 저장해 두고, 서버에 정보를 요청할 때
   HTTP 요청 헤더에 토큰을 포함시켜 전달한다.
3. 서버는 전달받은 토큰을 검증하고 요청에 응답한다.

Token의 구조

토큰은 헤더, 페이로드, 서명 3파트로 구분된다.

token

 

Header

JWT를 어떻게 검증하는가에 대한 내용을 담는다.
alg는 서명시 사용하는 알고리즘이고, kid는 서명시 사용하는 키 (public/private key)를 식별하는 값이다.

 

Payload

JWT의 내용으로서 Payload에 있는 속성들을 Claim Set이라고도 한다.

JWT에 대한 내용 (생성 정보, 일시 등등) 데이터로 구성된다.

 

Signature

점(.)을 구분자로 헤더와 페이로드를 합친 문자열을 서명한 값이다.

서명은 alg에 정의된 알고리즘과 비밀 키를 이용해 생성하고 base64로 인코딩한다.

 

 

Token의 단점

1. 토큰 데이터의 길이가 길기 때문에, 요청이 많아지면 네트워크 부하가 심해질 수 있다.
2. Payload는 암호화되지 않기 때문에 중요 정보를 담을 수 없다.
3. 토큰을 탈취 당하면 아몰랑

---