[WEEK00~WEEK01] 쿠키, 세션, JWT

1. 쿠키, 세션, JWT

1) 공통점

HTML의 Stateless, Connectionless를 보완하기 위해 탄생

 

2) 쿠키

- 등장배경 : 로그인 유지

- client-side

- little text-based files that are kept on their user’s computer accessible only by that user’s browser

- 클라이언트 측에 응답헤더의 Set-Cookie 정보를 담으며 key-value 형식의 문자열

 

단점

- 외부에 의해 탈취되었을 때 ID/PW 같은 민감한 정보도 함께 노출되기 쉬움 (요청시 쿠키의 값을 그대로 보내 보안에 취약)

- 용량 제한이 있어 많은 정보 담기 힘듦

 

3) 세션

- 등장배경 : 쿠키의 단점을 보완하여 세션 스토리지를 활용하여 보안성 강화

- server-side

- The data that is stored by session variables is either encrypted or converted to a binary form on the server 

- 인증정보는 서버에 저장, 클라이언트 식별자인 JSESSIONID를 쿠키에 담음

- 서버는 JSESSIONID 유효성 판별해 클라이언트 식별 

- 주로 로그인 등에 쓰임

 

단점

- http의 장점인 stateless를 위반 ( 서버에 세션 저장소를 사용하므로 stateful한 특징을 가지고 있음)

- stateful한 점을 고려할 시 로그인 정보가 서버에 저장되어 서버 비용문제 발생

- 유저가 늘어나면 메모리를 많이 차지함 ( 매번 서버에 호출시 서버에 부하가 걸리고 쿠키에 비해 속도가 느림)

 

3) JWT

session vs token

- http의 stateless한 특성으로 인해 통신의 상태가 저장되지 않음 => 세션과 토큰의 탄생
- 로그인을 시도할 때 인증을 위해 session or token을 발급
- 새로운 request를 보낼때마다 발급된 세션과 토큰을 보냄
- 차이점은 저장위치 =  session : DB서버 / token : 클라이언트에 저장

- 서비스가 커지고 대용량 트래픽을 대비하기 위해 확장성을 고려할 필요가 있음

- 세션은 사용자 많아질 시 서버에 과부하 생기고 로드밸런스 하면서 scale-out을 해야함 => 서버비용문제

- 토큰은 클라이언트에 access token 발급, signature 대조를 통해 인증 / 인가 방식 사용 => 비용부담줄임

- 토큰은 또한 발급주기에 차이를 두고 서버에 refresh token 발급하여 access token 재발급을 통해 정보 탈취에 대한 위험성 줄임

 

- 쿠키/세션과 비슷하게 JWT 토큰을 HTTP 헤더에 실어 서버가 클라이언트를 식별

- 세가지 문자열의 조합

   - Header : alg(해싱 알고리즘), typ(토큰의 타입 지정)

   - Payload : 토큰을 담을 정보 지님, 고유 ID값 및 유효기간 포함

   - Signature : Header와 Payload 더한 뒤 비밀키로 해싱하여 생성, 서버측의 비밀키가 유출되지 않는 이상 복호화 불가

 

장점

- Signature를 생성하므로 데이터 위변조 막을 수 있음

- 인증정보에 대한 별도 저장소 필요 없음 (stateless)

- 확장성 우수

 

[ 출처 ]

쿠키, 세션, JWT 등장배경

cookie / session의 기능과 JWT(Json Web Token)의 차이점

 

쿠키, 세션, JWT

인증 방식 : Cookie & Session vs JWT

쉽게 알아보는 서버 인증 1편(세션/쿠키 , JWT)