1. JWT와 세션, 쿠키의 차이
JWT (JSON Web Token)
- 구조:
header.payload.signature 형태의 JSON 기반 토큰
- 사용 방식: 서버에서 발급하고 클라이언트가 저장 후 요청 시 포함하여 인증
- 저장 위치: 일반적으로 Local Storage 또는 HTTP-Only 쿠키
- 장점:
- 자체적으로 사용자 정보를 포함할 수 있어 서버가 상태를 관리할 필요 없음 (Stateless)
- 확장성이 뛰어나고 여러 서비스에서 공유 가능
- 단점:
- 탈취 시 보안 취약 (만료 전까지 유효)
- 크기가 커질 수 있음 (세션보다 많은 정보 포함)
세션 (Session)
- 사용 방식: 사용자가 로그인하면 서버에서 세션을 생성하고, 클라이언트는 세션 ID를 쿠키에 저장하여 요청마다 전달
- 저장 위치: 서버 메모리, 데이터베이스, Redis 등에 저장
- 장점:
- 보안성이 높음 (토큰 자체에 정보가 없으므로 탈취되더라도 영향이 적음)
- 클라이언트에서 직접 관리할 필요 없음
- 단점:
- 서버에 저장하므로 확장성이 낮음 (로드 밸런싱 사용 시 sticky session 필요)
- 서버 리소스를 사용함
쿠키 (Cookie)
- 사용 방식: 클라이언트가 저장한 작은 데이터 조각을 요청 시 자동으로 서버에 전송
- 저장 위치: 클라이언트 브라우저
- 주요 목적:
- 사용자 상태 유지 (로그인 정보 저장)
- 웹사이트 설정 저장 (언어, 테마 등)
- 보안 이슈:
- HTTP-Only, Secure, SameSite 설정이 중요
- 탈취되면 세션 하이재킹 위험
차이점 정리
| 항목 | JWT | 세션 | 쿠키 |
|---|
| 저장 위치 | 클라이언트 (쿠키/로컬 스토리지) | 서버 (DB, 메모리) | 클라이언트 |
| 서버 확장성 | 높음 (Stateless) | 낮음 (Stateful) | N/A |
| 보안성 | 중간 (탈취 시 위험) | 높음 (세션 ID 관리 필요) | 중간 (HTTP-Only 설정 필요) |
| 사용 방식 | 자체 포함된 토큰 사용 | 서버에서 상태 유지 | 클라이언트 정보 저장 |
2. Access Token과 Refresh Token을 관리할 때 왜 Blacklist를 사용하지 않는가?
Blacklist란?
- Access token 또는 Refresh Token을 강제 만료시키기 위해 서버에서 유지하는 차단 목록
- 일반적으로 로그아웃, 비밀번호 변경, 계정 탈퇴 시 특정 토큰을 차단하는 용도로 사용됨
Blacklist 사용의 문제점
- Stateless 특성과 상충됨
- JWT 기반 인증은 서버가 상태를 유지하지 않는 것이 장점인데, Blacklist를 사용하면 서버가 인증 정보를 관리해야 함
- 세션 방식과 비슷해지면서 확장성이 떨어짐
- 서버 부담 증가
- 만료되지 않은 모든 토큰을 추적하려면 데이터베이스 또는 캐시에 저장해야 함
- 트래픽이 많아질수록 성능 저하 발생 가능
- 시간 차로 인한 비효율성
- 보통 Access token은 짧은 수명을 가지므로, 만료까지 대기하면 해결되는 경우가 많음
- 짧은 시간 동안 Blacklist를 유지하는 것보다 Access token이 자연스럽게 만료되는 것이 더 효율적
대안
- Access Token을 짧은 시간 (예: 15~30분) 동안만 유효하도록 설정하고, Refresh Token을 이용하여 새로운 Access Token을 발급하는 방식 사용
- Refresh Token을 데이터베이스에 저장하고, 로그아웃 시 해당 Refresh Token을 삭제하여 사용자가 새로운 Access Token을 받을 수 없도록 함
3. Access token과 Refresh token의 Lifetime 설정
Access token lifetime 결정 기준
- 일반적으로 15분 ~ 1시간 정도로 설정
- 기준:
- 보안: 탈취되었을 경우 피해를 최소화하기 위해 짧게 설정
- 사용자 경험: 너무 짧으면 자주 로그인이 필요하여 불편
- 트래픽 너무 짧으면 Refresh token사용 빈도가 높아져 서버 부하 증가
Refresh token lifetime 결정 기준
- 보통 7일 ~ 30일 정도로 설정
- 기준:
- 사용자 편의성: 너무 짧으면 자주 로그인해야 해서 불편
- 보안: Refresh token이 탈취되면 장기적으로 Access token을 무제한 발급 가능하므로 일정 기간 이후 강제 만료
- 저장 방식: 보통 데이터베이스에 저장하여 유효성을 검사할 수 있도록 함
실제 적용 예시
| 토큰 종류 | 유효 기간 | 설정 기준 |
|---|
| Access token | 15 ~ 30분 | 보안 vs 사용자 경험 |
| Refresh token | 7~ 30일 | 보안 vs 사용자 편의 |
