헤더/토큰 기반 인증 : 토큰 기반 인증

Token

 - 토큰의 정의, 필요성

 - 세션 기반 인증, 토큰 기반 인증의 차이점

 - 토큰 기반 인증의 동작 흐름

 - 토큰 기반 인증의 장점, 한계

 - RFC 표준과 Authorization 헤더의 활용 방식

 

토큰 기반 자격 증명 방식

1. 실생활에서의 토큰

 - 대중교통을 이용할 때 사용하는 토큰(카드)

 - 오락실에서 사용했던 동전 모양의 토큰

 - 행사 입장을 위해 나눠주는 토큰

 - 놀이공원 자유이용권 토큰

등등..

공통적으로 이 토큰들은 "서비스를 이용할 권리"에 대한 것이다.

애플리케이션 보안에서도 이와 비슷한 역할을 함

 

가령 빌딩에 방문했을 때, 안내 데스크에서 임시 출입 카드를 발급받는 상황에서,

 - 신원 정보 입력 = 자격 증명(Credential)

 - 임시 출입 카드 = 토큰

출입 카드를 가지고 빌딩에 있는 모든 문을 열 수 있는것은 아니며, 허용된 구역에서만 접근할 수 있다.

토큰 또한 특정 리소스에 대한 접근 권한을 부여한다.

 

2. 토큰 기반 인증의 특징

 - 토큰에 포함된 인증 정보는 서버가 별도로 상태를 저장하지 않는다

 - 생성된 토큰을 HTTP Authorization 헤더에 담아서 전송한다

 - 토큰 안에 사용자 정보가 포함되므로, 세션에 비해 네트워크 트래픽이 많을 수 있다

 - 서버는 토큰 자체를 관리하지 않기 때문에, 보안성 측면에서 더 신중한 설계가 필요하다

 - 인증 상태를 서버에 저장하지 않기 때문에 확장성(Scalability)면에서 매우 유리하다

 - 토큰은 암호화되지 않은 사용자 정보를 포함할 수 있기 때문에 민감한 정보는 토큰에 넣지 않아야함

 - 토큰은 만료되기 전까지는 기본적으로 무효화할 수 없다!

 - CSR(Client Side Rendering) 방식의 애플리케이션에 적합하다

 

* 세션 기반 인증은 서버를 확장할 때 세션 불일치 문제가 발생할 수 있지만,

Sticky Session, Session Clustering, 외부 세션 저장소(Redis 등..)로 보완한다.

* 토큰 기반 인증은 기본적으로 무효화할 수 없지만, Redis같은 인메모리 DB에 블랙리스트 형태로 저장하고 짧은 만료 시간을 부여하는 것으로 보완할 수 있다고 함

 

 

세션 기반 인증과 토큰 기반 인증의 비교

	세션 기반 인증	토큰 기반 인증
상태 관리	서버에 세션 저장소 필요	서버 상태 저장 불필요, 토큰만 검증
확장성	세션 공유 필요	서버 확장에 유리함
저장 위치	세션 스토리지, 로컬 스토리지	브라우저 쿠키
보안 위험	세션 탈취	토큰 유출
무효화	세션 만료시 서버에서 무효화 가능	만료 전까지 기본적으로 무효화 불가

 

 

토큰 기반 인증의 워크플로우

1. 과정

 1) 사용자가 아이디/비밀번호로 로그인 요청을 보냄

 2) 서버는 사용자 정보를 검증함

 3) 검증에 성공하면 서버는 토큰을 발급함

 4) 클라이언트는 토큰을 저장함

 5) 이후에 요청시, 클라이언트는 Authorization 헤더에 토큰을 담아 서버로 보냄

 6) 서버는 토큰의 유효성을 확인하고 요청을 처리함

 

2. 워크플로우 다이어그램

토큰 기반 인증 다이어그램

사용자가 서버에 로그인 요청 - > 서버는 사용자 정보를 검증하고 토큰을 발급

-> 이후 사용자가 서버에 Authorization 헤더로 요청을 보냄 - > 서버가 토큰의 유효성을 검증함

-> 토큰이 유효하다면 요청한 데이터 200 OK로 응답, 아니면 401로 응답

 

팁

 - HTTPS 필수 : 토큰은 평문 그대로 전달되므로 반드시 TLS(HTTPS)로 전송해야함

 - 만료 시간 관리 : 서비스 성격에 따라 적절히 조정해야함

 - 저장 위치 주의 : XSS 공격을 피하기 위해 localStorage보다는 HttpOnly 속성이 적용된 쿠키 사용을 권장함

 - 무효화 전략 : Redis같은 인메모리 DB에 블랙리스트 형태로 토큰을 저장해 강제 만료를 적용할 수 있음

 - 확장성 활용 : 서버 확장이 잦은 클라우드 환경에서는 세션 대신 토큰 기반 인증이 유리할 수 있음