Cookie, Session, JWT 쿠키, 세션, 토큰

---

관련된 HTTP 프로토콜의 특징

1. Connectionless
2. Stateless

• HTTP는 기본적으로 서버의 부담을 줄이기 위해 비연결성과 무상태의 특성을 가진다.
• 클라이언트는 데이터를 요청할 때마다 인증 필요
• 이를 해결하기 위해 쿠키와 세션을 사용

HTTP Cookie 쿠키

• 클라이언트에 저장되는 key 와 value 로 이루어진 데이터
• 인증 유효 기간을 설정할 수 있다.
• 유효 시간이 정해진다면 클라이언트가 종료 되어도 쿠키 유지

쿠키 동작 방식

1. 클라이언트 로그인 요청
2. 서버에서 쿠키 생성 후 클라이언트로 전달
3. 클라이언트 서버로 요청 보낼 때 쿠키 전송
4. 쿠키로 유저 인증 진행

쿠키의 문제점

• 사용자 인증 정보를 모두 클라이언트가 가지고 있다.
• HTTP 요청시 쿠키 자체를 탈취 당해 사용자 정보를 뺏길 수 있다.
• 보안과 상관 없는 장바구니나 자동 로그인 설정등에 사용

Session 세션

• 쿠키를 기반으로 하지만 서버에 저장하여 관리
• 클라이언트를 구별하기 위해 클라이언트마다 세션 ID 부여
• 세션 ID 는 클라이언트 종료까지 유지
• 클라이언트에 저장하는 쿠키보다 보안이 좋다.

세션 동작 방식

1. 클라이언트 로그인 요청
   1. 서버에서 클라이언트에게 고유 세션 ID 를 부여
   2. 고유 세션 ID 세션 저장소에 저장
   3. 고유 세션 ID 클라이언트에 발급
2. 클라이언트는 발급 받은 세션 ID 를 쿠키에 저장 후 요청시 쿠키 전송
3. 서버는 쿠키에 있는 세션 ID 와 세션 저장소에 있는 정보를 대조

세션의 문제점

• 세션 하이재킹 공격이 가능하다.
• 세션의 유효 시간을 만들어 예방
• 세션 저장소를 서버에서 관리
• 동시 접속자가 많아지면 서버에 걸리는 부하 증가

Json Web Token JWT 토큰

• 인증에 필요한 정보를 암호화 시킨 토큰
• 쿠키에 담아서 보내거나 HTTP 헤더에 담아서 보낼 수 있다.

토큰 요소 3가지

• Header: 3가지 요소를 암호화할 알고리즘 같은 옵션이 들어간다.
  • Signature 를 해싱하기 위한 알고리즘 정보가 담겨있다.
• Payload: 유저의 고유 ID 등 인증에 필요한 정보가 들어간다.
  • 서버와 클라이언트가 주고받는 시스템에서 실제로 사용될 정보에 대한 내용들을 담고 있다.
• Verify Signature: Header, Payload Secret Key 암호화
  • 토큰의 유효성 검증을 위한 문자열

토큰 동작 방식

1. 클라이언트가 로그인 요청
2. 서버에서 유저의 고유한 ID 와 다른 인증 정보들과 함께 Payload 에 담는다.
3. JWT의 유효기간 설정 및 옵션 설정
4. Secret Key 를 이용해 토큰 발급
5. 발급된 토큰은 클라이언트에 쿠키 혹은 로컬 스토리지 등에 저장하여 요청을 보낸다.
6. 서버는 토큰을 Secret Key 로 보호화하여 검증 과정 진행

토큰의 문제점

• 토큰은 세션보다 간편하다.
• 세션처럼 별도의 저장소 관리가 필요 없고 토큰 발급 후 클라이언트 전송 및 검증 과정만 있으면 작동
• 발급된 JWT 는 삭제 불가
• 악의적으로 사용되는 세션은 삭제하면 해결
• 토큰은 유효 기간이 종료되기 전까지 악의적 사용 해결 불가