JWT 방식
클라이언트와 서버 간 인증 정보를 JSON 형식으로 인코딩한 토큰을 통해 교환하는 방식
토큰은 클라이언트에 저장되고(보통 Local Storage나 쿠키에 저장), 서버는 토큰 검증 수행
장점
- 확장성: 서버는 토큰을 검증하기만 하면 되므로 상태를 유지하지 않아도 되어 수평 확장(Scalability)에 유리
- 서버 부하 감소: 서버가 세션을 저장하지 않으므로 메모리 사용량이 적음
- 다양한 클라이언트 지원: 웹, 모바일, 외부 API 등 여러 클라이언트에서 동일한 토큰 사용 가능
- 무상태성(Stateless): 서버는 사용자의 로그인 상태를 유지하지 않으므로 RESTful 서비스에 적합
- 소셜 로그인: JWT는 소셜 로그인과 잘 맞으며, OAuth 2.0에서 주로 사용됨
단점
- 토큰 탈취 위험: 토큰이 클라이언트에 저장되므로 탈취되면 만료 전까지 막을 방법이 없음
- 로그아웃 어려움: 서버에서 강제 만료 어려움 (재발급 시 블랙리스트 관리 필요)
- 토큰 크기: 서명(signature) 및 페이로드가 포함되므로 세션 ID보다 크기가 커질 수 있어 네트워크 트래픽 증가 가능성 있음
- 민감 정보 노출 가능성: 페이로드는 인코딩된 형태일 뿐 누구나 디코딩할 수 있으므로, 민감한 정보를 포함해서는 안 됨
세션 방식
서버가 클라이언트의 상태를 저장하고 관리
클라이언트는 세션 ID를 쿠키에 저장하고 요청 시마다 쿠키를 서버로 전송
장점
- 보안: 세션 정보는 서버에만 저장되므로 JWT보다 상대적으로 안전
- 로그아웃 처리 용이: 세션 삭제로 즉각적인 로그아웃 가능
- 유연성: 서버에서 사용자 상태를 자유롭게 관리할 수 있어 복잡한 인증/인가 요구사항 처리 용이
- 세션 무효화: 서버에서 관리하므로 필요 시 세션 강제 만료 가능
단점
- 서버 부하 증가: 서버가 모든 사용자 세션 정보를 저장해야 하므로 메모리와 스토리지 자원 필요
- 확장성 문제: 여러 서버(분산 서버)에서 세션 상태를 공유하려면 세션 저장소(Redis, DB 등)가 필요하며, 복잡성 증가
- 무상태성 위반: RESTful 원칙을 따르지 않아 일부 아키텍처에 적합하지 않을 수 있음
JWT vs 세션 선택 기준
| 기준 | JWT | 세션 |
|---|---|---|
| 확장성 | 서버 상태를 저장하지 않아 유리 | 서버 상태 저장으로 불리 |
| 보안 | 토큰 탈취 시 취약 | 서버 관리로 상대적으로 안전 |
| RESTful 호환성 | 매우 적합 | 덜 적합 |
| 로그아웃 구현 용이성 | 어려움(블랙리스트 필요) | 쉬움 |
| 데이터 저장 위치 | 클라이언트(토큰) | 서버 |
| 트래픽 비용 | 토큰 크기로 인해 약간 증가 가능 | 비교적 낮음 |
| 사용자 상태 관리 | 어려움 | 용이 |
참고: chatGPT
CS 메모장