[인증] Session-based와 Token-based

Session-based와 Token-based 인증의 차이는 주로 인증 데이터를 저장하고 관리하는 방식과 그에 따른 동작 차이에 있다.

 

Session-based Authentication (세션 기반 인증)

 

동작 방식

• 사용자가 로그인하면 서버는 사용자 정보를 기반으로 세션을 생성하고, 해당 세션 ID를 쿠키에 저장해 클라이언트에 전달
• 이후 클라이언트는 요청마다 쿠키에 담긴 세션 ID를 서버에 전송
• 서버는 세션 저장소에서 이 세션 ID를 확인해 사용자 정보를 인증

특징

• 세션 데이터는 서버에 저장되며, 클라이언트는 세션 ID만 보유
• 서버가 상태(state)를 유지해야 함 (stateful)

장점

• 서버가 세션 데이터를 직접 관리하므로 보안이 상대적으로 강함
• 세션 만료 등 세부 제어가 용이

단점

• 서버에 세션 저장소를 유지해야 하므로, 많은 사용자가 접속하면 서버 자원 소모가 큼
• 분산 서버 환경에서 세션 공유를 위한 추가 설정(ex. Redis) 필요
• 클라이언트-서버 간 동일 도메인에서만 활용하기 편리

 

Token-based Authentication (토큰 기반 인증)

동작 방식

• 사용자가 로그인하면 서버는 사용자의 인증 정보를 기반으로 JWT(JSON Web Token) 또는 기타 토큰을 생성해 클라이언트에 전달
• 클라이언트는 이 토큰을 로컬 스토리지나 쿠키에 저장
• 이후 요청 시 토큰을 Authorization 헤더에 담아 서버로 전송
• 서버는 토큰을 검증해 사용자 정보를 인증

특징

• 클라이언트에 인증 정보를 포함한 토큰이 저장되며, 서버는 별도의 상태를 유지하지 않음 (stateless)
• 주로 JWT를 사용하여 자체적으로 서명된 토큰을 생성함

장점

• 서버 상태를 유지하지 않아 확장성이 좋고 분산 서버 환경에 적합
• CORS 설정이 허용된다면 다른 도메인에서도 사용 가능
• 토큰에 사용자 권한 정보 등을 포함하여 클라이언트-서버 간 추가 요청 감소 가능

단점

• 토큰 탈취 시 보안 위험 (토큰은 클라이언트에 저장되므로)
• 토큰이 만료되거나 재발급되는 과정에서 복잡성이 증가할 수 있음
• 토큰 크기가 세션 ID보다 커서 요청 시 데이터 전송량이 증가

 

저장 위치	서버 (세션 저장소)	클라이언트 (로컬 스토리지, 쿠키 등)
서버 상태	Stateful (서버에서 세션 유지)	Stateless (서버에서 상태 유지 없음)
확장성	제한적 (서버 부하 증가)	우수 (분산 시스템에 적합)
보안성	상대적으로 강함	토큰 탈취 시 취약 가능성
사용 사례	내부 서비스, 동일 도메인 환경	모바일 앱, 분산 시스템, API 서버

 

 

선택의 기준

Session-based

• 소규모 애플리케이션, 동일 도메인 내에서 사용, 서버 부하가 적은 경우 적합
• 보안이 우선시되는 애플리케이션 (특히 민감 데이터 관리)

Token-based

• 분산 환경(ex. 마이크로서비스), 모바일 앱, 다중 클라이언트(웹, 모바일) 지원이 필요한 경우 적합
• 확장성과 클라이언트 독립성이 중요한 경우

 

물론 필요에 따라 두 방식을 혼합하여 사용할 수도 있다.