세션 기반 인증과 JWT 기반 인증은 모두 사용자의 인증 상태를 관리하는 방법이지만, 구현 방식과 동작 방식에 큰 차이가 있다.
1. 세션 기반 인증
동작 방식:
- 사용자가 로그인하면 서버는 사용자의 인증 정보를 기반으로 세션을 생성.
- 서버는 세션 ID(Session ID)를 클라이언트에 쿠키로 전달.
- 클라이언트는 이후 요청마다 쿠키에 세션 ID를 담아 서버로 전달.
- 서버는 세션 ID를 기반으로 세션 스토리지(메모리, 데이터베이스 등)에 저장된 인증 정보를 확인하여 사용자를 인증.
특징:
- 인증 정보 저장: 서버가 세션 스토리지를 관리합니다.
- 유효성 검증: 서버가 세션 ID를 확인해야 하므로 서버 상태(stateful)를 유지.
- 보안: 세션 ID가 클라이언트에서 탈취되면 공격자가 사용자를 가장할 수 있음.
- 스케일링: 서버 확장이 어렵습니다. (여러 서버가 동일한 세션 정보를 공유해야 하므로 세션 복제나 별도의 세션 스토리지가 필요.)
장점:
- 간단하게 구현 가능.
- 세션 정보를 서버에서 직접 관리하므로 클라이언트는 정보를 신경 쓸 필요 없음.
단점:
- 서버가 상태를 유지해야 하므로 서버 리소스 사용량이 증가.
- 클라이언트-서버 간 강한 의존성.
2. JWT 기반 인증
동작 방식:
- 사용자가 로그인하면 서버는 사용자 인증 정보를 기반으로 JWT(Json Web Token)를 생성하여 클라이언트에 전달.
- 클라이언트는 JWT를 로컬 스토리지, 세션 스토리지, 또는 쿠키에 저장.
- 이후 요청마다 클라이언트는 JWT를 HTTP 헤더(보통 Authorization: Bearer <token>)에 담아 서버로 전달.
- 서버는 JWT의 서명을 검증하여 사용자를 인증.
특징:
- 인증 정보 저장: 클라이언트가 JWT를 보관.
- 유효성 검증: 서버는 JWT의 서명만 확인하므로 상태를 유지하지 않음(stateless).
- 보안: JWT 탈취 시 클라이언트는 공격자를 방지할 방법이 제한적이므로 HTTPS를 반드시 사용해야 함.
- 스케일링: 서버가 상태를 유지하지 않으므로 수평 확장이 용이.
장점:
- 서버가 상태를 유지하지 않아 확장이 쉬움.
- 여러 서비스(API Gateway 등) 간 인증 정보 공유가 편리.
단점:
- JWT는 클라이언트에 저장되므로, 만료 전에는 언제든 탈취될 가능성이 있음.
- 한 번 발급된 JWT는 만료될 때까지 유효하므로 서버에서 강제로 무효화하기 어려움(리프레시 토큰으로 보완 가능).
- JWT가 비교적 크기 때문에 네트워크 부하가 증가할 수 있음.
3. 차이점 비교
구분 | 세션 기반 인증 | JWT 기반 인증 |
인증 정보 저장 | 서버의 세션 스토리지 | 클라이언트(JWT 저장) |
상태 | 상태 유지(stateful) | 무상태(stateless) |
확장성 | 서버 확장이 어렵고 부하가 증가함 | 서버 확장이 쉬움 |
유효성 관리 | 서버가 세션을 삭제하면 즉시 인증 무효화 가능 | JWT 만료 시간을 설정해야 함 |
보안 | 세션 ID 탈취 방지 필요 | JWT 탈취 및 재사용 방지 필요 |
사용 사례 | 소규모 애플리케이션, 내부 네트워크 환경 | 대규모 분산 시스템, API 인증 |
성능 | 서버 스토리지 및 I/O 부하 | 서버 부하 낮음, 네트워크 부하 증가 가능 |
4. AppConfig에서 JWT 활용
AppConfig는 JWT 기반 인증에서 **서버의 비밀 키(secret key)**를 관리합니다. JWT는 이 키를 사용하여 생성되고 검증되므로, 키가 노출되지 않도록 안전하게 관리해야 합니다
chaewon:
jwtKey: "yourBase64EncodedSecretKey"
- jwtKey: JWT 생성 및 검증에 사용되는 비밀 키.
- JWT 기반 인증을 구현하려면 이 키를 사용하여 토큰을 생성(HS256과 같은 알고리즘)하고 서명을 검증합니다.
5. 어떤 방식을 선택해야 할까?
- 세션 기반 인증:
- 소규모 프로젝트, 단일 서버 환경에 적합.
- 구현이 간단하고 서버에서 직접 세션 관리 가능.
- JWT 기반 인증:
- RESTful API, 마이크로서비스, 대규모 분산 시스템에 적합.
- 서버가 상태를 유지하지 않으므로 확장성이 뛰어남.
개인프로젝트를 진행하며 Spring security와 JWT 조합으로 사용할까 했지만 이미 세션 기반으로 구현한 상태에서 JWT로 변경을 하기에는 많은 부분을 변경해야했기 때문에 그대로 세션으로 진행했다.
기회가 된다면 후에 시간이 넉넉할 때 리팩토링을 해보는 것으로!
'Spring' 카테고리의 다른 글
[SpringRestDocs] Unresolved directive in index.adoc-... (0) | 2024.12.10 |
---|---|
[Spring] 단위테스트에서 MockBean과 Autowired의 차이 (0) | 2024.08.13 |
[Spring MVC]예외 처리와 오류 페이지 (1) | 2023.11.27 |
[Spring MVC] 로그인 처리(2) - 필터, 인터셉트 (1) | 2023.10.23 |
[Spring MVC] 로그인 처리 (1) - 쿠키, 세션 (1) | 2023.10.10 |