Session 기반 인증과 JWT의 차이
Session 기반 인증과 JWT의 차이
개요
HTTP는 기본적으로 stateless한 프로토콜이다.
즉, 각각의 요청은 서로 독립적이며 서버는 이전 요청의 상태를 기억하지 않는다.
하지만 로그인과 같은 기능을 구현하려면,
서버는 “이 요청이 어떤 사용자로부터 온 것인지”를 식별할 수 있어야 한다.
이 문제를 해결하기 위해 등장한 대표적인 방식이 세션(Session) 기반 인증과
JWT(JSON Web Token) 기반 인증이다.
Session 기반 인증
개념
세션 기반 인증은 로그인 정보를 서버 측에 저장하고,
클라이언트는 해당 세션을 식별할 수 있는 세션 ID만을 전달하는 방식이다.
일반적인 흐름은 다음과 같다.
- 사용자가 로그인 요청을 보낸다.
- 서버는 사용자 정보를 검증한 후 세션을 생성한다.
- 서버는 세션 ID를 쿠키로 클라이언트에 전달한다.
- 이후 요청마다 클라이언트는 쿠키에 담긴 세션 ID를 함께 전송한다.
- 서버는 세션 ID를 기반으로 사용자 상태를 조회한다.
특징
- 서버가 인증 상태를 직접 관리
- 보통 쿠키를 통해 세션 ID 전달
- Stateful 구조
장점
- 구현이 비교적 단순
- 서버에서 세션을 직접 제어 가능
- 로그아웃 처리 용이
단점
- 서버 메모리 사용 증가
- 서버 확장 시 세션 공유 필요 (Sticky Session, Redis 등)
- 대규모 트래픽 환경에서 관리 비용 증가
JWT 기반 인증
개념
JWT 기반 인증은 인증 정보를 토큰 자체에 포함시켜 클라이언트에 전달하는 방식이다.
JWT는 다음 세 부분으로 구성된다.
- Header
- Payload
- Signature
서버는 토큰을 발급한 이후, 별도의 상태를 저장하지 않는다.
동작 방식
- 사용자가 로그인 요청을 보낸다.
- 서버는 사용자 정보를 검증한 후 JWT를 발급한다.
- 클라이언트는 JWT를 저장한다. (로컬 스토리지, 쿠키 등)
- 이후 요청마다 Authorization 헤더에 JWT를 포함해 전송한다.
- 서버는 토큰의 서명과 만료 시간을 검증한다.
특징
- Stateless 구조
- 서버 확장에 유리
- 토큰 자체에 사용자 정보 포함
장점
- 서버 확장성 우수
- 별도의 세션 저장소 불필요
- 마이크로서비스 환경에 적합
단점
- 토큰 크기가 큼
- 토큰 탈취 시 위험
- 로그아웃 처리 어려움 (토큰 무효화 문제)
Session vs JWT 비교
| 항목 | Session | JWT |
|---|---|---|
| 상태 관리 | Stateful | Stateless |
| 저장 위치 | 서버 | 클라이언트 |
| 확장성 | 낮음 | 높음 |
| 로그아웃 | 쉬움 | 어려움 |
| 보안 | 서버 중심 | 토큰 관리 중요 |
언제 어떤 방식을 선택할까?
Session이 적합한 경우
- 소규모 서비스
- 단일 서버 환경
- 보안과 제어가 중요한 경우
JWT가 적합한 경우
- 분산 시스템
- 마이크로서비스 아키텍처
- 모바일·SPA 기반 서비스
정리
Session과 JWT는 서로 대체 관계라기보다, 상황에 따라 선택되거나 함께 사용되기도 하는 인증 방식이다.
- Session은 단순하고 직관적인 인증 방식
- JWT는 확장성과 분산 환경을 고려한 인증 방식
서비스의 규모, 아키텍처, 보안 요구사항을 고려하여 적절한 인증 방식을 선택하면 된다.
This post is licensed under CC BY 4.0 by the author.