[JWT] 자격 증명 방식 : 세션 기반 vs 토큰 기반

 

 

* 세션? 

: HTTP 가 비연결성(Connectionless), 비상태성(Stateless)의 특성을 가지고 있기 때문에

인증된 사용자 request의 상태를 유지하기 위한 수단!

 

 

세션 기반 자격 증명 방식? 

: 서버 측에 인증된 사용자의 정보를 세션 형태로 세션 저장소에 저장

 

클라이언트한테 요청이 들어오면, 세션 저장소에 저장된 세션 정보 = 사용자가 제공하는 정보가 일치하는지 확인

 

 

세션 기반 자격 증명의 특징

• 인증된 사용자 정보 : 서버 측 세션 저장소에서 관리
• 세션 ID (=사용자 세션의 고유 ID) 쿠키에 저장되어 인증된 사용자 증명 수단으로 사용
• 상대적으로 적은 네트워크 트래픽 (서버 측에서 세션 정보 관리)
• 세션 불일치 문제 발생 가능성 ⬆ (서버의 확장성 면)
• 세션 데이터 ⬆, 서버의 부담 ⬆
• SSR(Server Side Rendering) 방식의 애플리케이션에 적합

 

 

↕

 

 

 

* 토큰? 

: 인증된 사용자의 자격을 증명 + 접근 권한을 부여(특정 리소스에만 접근 가능)

 

ex) 특정 빌딩 방문시 안내데스크에서 입시 출입 카드를 부여 받았을 경우,

방문자 목록에 적는 신원 정보 = 자격 증명 정보 (Credential)

입시 출입 카드 = 토큰

 

 

토큰 기반 자격 증명 방식? :

: 인증된 사용자의 정보를 토큰에 저장하고,

접근 권한을 부여해 접근 권한이 부여된 특정 리소스에만 접근이 가능하게 하는 방식

 

 

세션 기반 자격 증명의 특징

• 토큰 : 인증된 사용자 정보 포함 ➡ 서버 측에서 별도의 관리 X
• request 전송시 생성된 토큰 헤더에 포함 ➡ 인증된 사용자인지 증명하는 수단
• 세션에 비해 상대적으로 많은 네트워크 트래픽 : 토큰 내에 인증된 사용자 정보 등 포함
• 보안성 측면에서 조금 더 불리 : 서버 측에서 토큰 관리 안하기 때문
• 서버의 확장성 면에서 유리 ⬅ 인증된 사용자 request 상태 유지할 필요 X (토큰 보유? = 인증되었단 뜻)
• 세션 불일치 문제 X
• 토큰 탈취 ➡ 사용자 정보 그대로 공개!, 토큰에 민감한 정보 포함 X
• 토큰 만료 전까지 토큰 무효화 X
• CSR(Client Side Rendering) 방식의 애플리케이션에 적함