Session-based와 Token-based 인증의 등장 배경
-
HTTP는 Stateless(무상태) 프로토콜로, 서버가 클라이언트의 상태를 유지하지 않아 클라이언트가 매 요청마다 서버에게 인증해줘야함.
-
어떻게 인증을 쉽게 할것인가?
Session-based Authentication(인증)
서버가 클라이언트의 상태를 기억할수 있도록 Session을 도입.
-
서버가 사용자를 식별할 수 있도록 세션 저장소에 사용자의 상태를 저장.
-
클라이언트는 세션 ID를 쿠키로 저장하고, 요청 시마다 이를 서버에 전달.
-
서버는 세션 ID를 기반으로 클라이언트를 식별하고 인증 상태를 확인
이런 인증방식 덕분에 쿠키로 Stateful(상태성)하게 된다
Session-based Authentication의 한계
1. 확장성 문제 (Scalability)
- 서버가 모든 세션 정보를 저장해야 하므로 메모리와 자원 소모가 커짐.
- 서버가 여러 대일 경우, 각 서버 간 세션 데이터를 동기화해야 하는 부담이 생김.
2. 보안 문제
- 세션 ID 탈취(Session Hijacking)로 인해 보안 위협 발생 가능.
- 서버에 저장된 세션 데이터가 공격당할 경우 전체 사용자의 정보가 유출될 위험.
3. 분산 시스템 및 클라우드 환경의 등장
- 서버가 유동적으로 확장 및 축소되는 클라우드 환경에서는 상태 정보를 관리하는 것이 비효율적.
- 서버 간 상태 정보를 공유하지 않는 Stateless 방식이 필요.
Session-based 인증방식의 한계로 인하여 Token-based 인증방식 탄생
Token-based Authentication(인증)
세션 상태를 서버가 아닌 클라이언트에 저장하는 방법.
1. JSON Web Token (JWT)과 같은 기술을 활용해, 인증 정보를 포함한 토큰(Token)을 클라이언트에 전달.
2. 서버는 클라이언트가 보낸 토큰만 검증하며, 세션 정보를 따로 저장하지 않음.
이런 인증방식 덕분에 쿠키로 Stateless(무상태성)하게 된다.
개념 충돌!!!! Cookie는 Stateful인가? Stateless인가?
- 쿠키가 어떤 방식의 인증을 위해 존재 여부에 따라 Stateless와 Stateful이 결정된다.
- 물론 보편적으로 Session-based 방식을 사용해왔기 때문에 Stateful이라고 알고있다.
