세션과 토큰 로그인
토큰을 실습 위주로 갈 예정이지만, 세션도 여전히 중요하다(특히 MVC에서 많이 등장).
웹에서 로그인(인증)을 구현할 때 대표적으로 쓰는 방식이 세션 기반 인증과 토큰 기반 인증(JWT) 이다.
- 사용자에게 인증값이 전달되는 과정
세션 방식 (Session-Based Authentication)
세션은 “로그인 상태”를 서버가 저장하는 방식이다.
클라이언트는 세션ID(인증값)를 들고 다니고, 서버는 그 세션ID가 유효한지 서버 저장소에서 확인한다.
동작 흐름
- 로그인 요청
- 서버가 DB로 사용자 정보 검증
- 서버가 세션ID 생성
- 서버 저장소(메모리 등)에
세션ID ↔ 사용자 정보저장 - 클라이언트에게 세션ID 전달
- 클라이언트는 세션ID를 보통 쿠키에 저장
- 이후 요청마다 쿠키로 세션ID 전송
- 서버는 저장소의 세션 정보와 비교해 인증 처리
세션ID는 뭐냐?
- 세션ID = 인증값(난수/암호화된 값 정도로 이해)
- 서버 저장소에는 “그 세션ID가 누구인지” 같은 인증 정보가 같이 저장됨
→ 그래서 세션은 서버가 상태를 들고 있는 stateful 방식이다.
세션 방식 단점
- 로그인 사용자가 많아질수록 세션이 쌓여서 메모리 부하가 커짐
- 서버를 여러 대로 늘리면(스케일 아웃) 로드밸런싱 때문에 요청이 다른 서버로 가서
“세션이 없는 서버”에 도착하면 인증이 깨질 수 있음 - 개선은 가능
- DB에 세션 저장: 공유는 되지만 성능 부담 가능
- Redis 같은 캐싱 DB로 세션 저장: 공유 + 성능을 같이 챙기는 방향
토큰 방식 (Token-Based Authentication, JWT)
토큰 방식은 서버가 토큰(JWT)을 발급하고, 클라이언트가 그 토큰을 들고 다니면서 요청마다 제출하는 방식이다.
핵심은 토큰을 서버가 저장하지 않고, 서버는 토큰을 “자체 검증”한다는 점이다(무상태에 가까움).
동작 흐름
- 로그인 요청
- 서버가 DB로 사용자 정보 검증
- 서버가 토큰(JWT) 발급
- 클라이언트가 토큰 저장(서비스 정책에 따라 쿠키/스토리지 등)
- 이후 요청마다 토큰을 담아서 전송(보통
Authorization헤더) - 서버는 토큰의 서명/만료 등을 검증해서 인증 처리
“저장 안 하는데 어떻게 검증함?”
- 토큰은 구조가 있고(서명 포함), 서버는 그 서명이 유효한지 확인해서 “위조/변조 여부”를 판단한다.
- 그래서 DB나 메모리에 세션처럼 저장하지 않아도, 토큰만 보고 유효성을 확인할 수 있다.
토큰 방식 단점(중요)
- 토큰을 탈취당하면, 서버 입장에서는 그 토큰이 정상 형태면 막기가 어렵다
- 세션처럼 “서버에서 세션 삭제”로 즉시 강제 로그아웃시키는 방식이 잘 안 된다
- 그래서 보통 같이 쓰는 대응이 있음
- 토큰 만료시간을 짧게 가져감
- access / refresh 토큰 분리 운영 등으로 피해 범위를 줄임
세션 vs 토큰 한 줄 정리
- 세션: 서버가 로그인 상태를 저장하고, 클라이언트는 세션ID만 들고 다닌다.
- 토큰: 서버는 상태를 저장하지 않고, 클라이언트가 토큰을 들고 다니며 서버는 토큰 자체를 검증한다.
Eazy하게