로그인 인증 상태를 유지하는 대표적인 두 가지 방식인 Session과 JWT(JSON Web Token)의 동작 과정과 특징을 한눈에 비교 정리한 포스트입니다.
사용자의 로그인 인증 정보를 서버 메모리(저장 공간)에 직접 보관하는 전통적인 방식입니다.
세션 생성 및 쿠키 발급 (Server ➔ Client)
JSESSIONID)를 생성합니다.Set-Cookie에 키를 담아 클라이언트에 전달합니다.Set-Cookie: JSESSIONID=abc123
요청 시 쿠키 자동 동봉 (Client ➔ Server)
Cookie 헤더에 JSESSIONID를 자동으로 포함해 전송합니다.Cookie: JSESSIONID=abc123
유저 식별 (Server)
JSESSIONID를 확인합니다.💡 특징: 서버가 세션 상태를 메모리에 보관하므로 Stateful(상태 유지)한 특성을 갖습니다.
인증에 필요한 정보들을 JSON 형태로 암호학적 서명과 함께 압축해 전달하는 토큰 규격입니다.


HS256 등) 및 토큰 타입 정보(Header + Payload)와 비밀키로 생성한 위·변조 방지 검증값| 클레임 키 | 설명 |
|---|---|
sub (Subject) | 토큰의 주체 식별자 (주로 회원 ID / 고유 식별값) |
iat (Issued At) | 토큰 발급 시각 (UNIX Timestamp) |
exp (Expiration) | 토큰 유효기간 만료 시각 |
role | 사용자의 권한 등급 (예: USER, ADMIN) |
| 비교 항목 | Session | JWT |
|---|---|---|
| 저장 위치 | 서버 메모리 / 세션 저장소 | 클라이언트 (로컬 스토리지, 쿠키 등) |
| 식별 데이터 형태 | 의미 없는 고유 키 문자열 (JSESSIONID) | 유저 정보가 직렬화되어 담긴 자체 완결적 토큰 |
| 서버 특성 | Stateful (서버가 세션 상태를 기억함) | Stateless (서버가 상태를 보관하지 않음) |
| 서버 확장성 | 서버 증설 시 세션 클러스터링/동기화 필요 | 서명 검증만 수행하므로 다중 서버 확장에 매우 유리 |
💡 핵심 요약:
Session Key는 그 자체로 아무 의미 없는 난수 문자열이지만,
JWT는 토큰 자체에 모든 로그인 정보가 포함되어 있습니다.
따라서 서버가 세션을 보관할 필요 없이 서명 검증만으로 즉시 유저 식별이 가능합니다.
Stateless한 특성을 갖습니다.
Signature = {암호화알고리즘}(Base64Url(Header) + "." + Base64Url(Payload), SecretKey)
https://emn178.github.io/online-tools/base64_encode.html
