전통적인 세션 ID 기반 인증과 JWT(Json Web Token) 기반 인증 비교
로그인 세션 관리에서 전통적인 세션 ID 기반 인증과 JWT(Json Web Token) 기반 인증은 가장 많이 사용되는 두 가지 방식입니다. 아래는 이 둘의 차이점과 장단점을 비교한 표입니다:
| 항목 | 세션 ID 기반 인증 | JWT 기반 인증 |
|---|---|---|
| 인증 방식 | 서버가 세션 ID를 생성하고 클라이언트에 전달 (주로 쿠키에 저장) | 서버가 JWT를 생성하고 클라이언트에 전달 (주로 헤더나 로컬스토리지/쿠키에 저장) |
| 서버 저장소 필요 | 필요 (서버에 세션 저장) | 불필요 (토큰 자체에 정보 포함) |
| 확장성 | 낮음 (세션 저장소 공유 필요) | 높음 (무상태 Stateless 구조) |
| 보안성 | 세션 탈취 위험, 하지만 서버에서 세션 무효화 가능 | 탈취 시 만료 전까지 유효, 무효화 어려움 (추가 로직 필요) |
| 토큰 크기 | 작음 (세션 ID) | 큼 (Base64 인코딩된 JSON) |
| 무효화 처리 | 서버에서 세션 삭제 | 보통 불가능, 블랙리스트 관리 등 별도 구현 필요 |
| 관리 편의성 | 서버가 통제 가능 | 클라이언트 주도, 설계 복잡 |
| 사용처 | 전통적인 웹 앱 (서버 렌더링) | SPA, 모바일 앱, 마이크로서비스 구조 등 |
간단 요약
-
세션 ID 기반 인증
-
서버 중심. 서버가 상태를 유지함.
-
세션을 쉽게 만료시키거나 무효화할 수 있어 보안 제어가 용이.
-
수평 확장 시 세션 공유 필요 (ex. Redis 사용).
-
-
JWT 기반 인증
-
클라이언트 중심. 서버는 상태를 유지하지 않음 (Stateless)
-
확장성에 유리, 마이크로서비스에 적합.
-
무효화가 어려워 보안 이슈에 취약할 수 있음.
-
선택 기준
| 상황 | 추천 방식 |
|---|---|
| 전통적인 웹 사이트 (로그인, 로그아웃, 쇼핑몰 등) | 세션 ID |
| SPA, 모바일 앱, API 서버 (마이크로서비스 구조) | JWT |
| 인증 정보 자주 바뀌는 경우 (권한, 유효시간 등) | 세션 ID |
| 서버 간 인증 필요 (S2S, 분산 인증 등) | JWT |
jwt는 발급된 후에는 변경이나 제어가 불가능 하기 때문에, 덜 중요한 곳에서 쓰는게 좋음. 그리고 유효기간을 짧게해서 주기적으로 유효성을 검사하도록.
서버 저장소 확인할 필요가 없어서 인증부하가 낮음.
token 발급자 (issuer)를 믿고 동작하는 서비스는 jwt 가 낫다.
아무튼, JWT, JWE 구현 기법 공부하다가, 알아봄.
https://openauth.js.org/ 예제가 잘 구현되어 있더라. 한번쯤 구동해보길 권장함.