[Spring Security] [세션/토큰 방식]

 

토큰인증 기반을 쓰는이유
세션기반인증은 서버 혹은DB에 유저 정보를 담는 방식 > 서버에 부하가 발생함 
대표적인 토큰 기반 방식 > JWT (Json Web Token)

토큰은 유저 정보를 암호화한 상태로 담을 수 있고, 암호화 했기 때문에 클라이언트에 담을 수 있다.

토큰 기반 자격 증명

HTTP 프로토콜은 Request를 전송한 후 Response를 수신하게 되면 연결을 끊는 비연결성(Connectionless)의 특성을 가지고 있고 또한 Request와 Response에 대한 상태를 저장하지 않는 비상태성(Stateless)의 특성을 가지고 있기 때문에 로그인 인증을 성공적으로 수행되었다 하더라도 서버측에서는 매번 Request를 수신할 때마다 이 Request가 인증된 사용자가 보낸 Request인지 알수있는 방법이 없다 
이러한 HTTP 특성으로 인해 사용자의 인증이 성공적으로 이루어졌을 때 인증된 사용자 Request의 상태를 유지하기 위한 수단이 필요하게 되었으며 대표적인 수단이 바로 세션이다.

 

세션 기반 자격 증명 방식

세션 기반 자격 증명 방식은 서버 측에 인증된 사용자의 정보를 세션 형태로 세션 저장소에 저장하는 방식이다 즉 클라이언트 측에서 서버 측의 리소스를 요청하면 서버 측에서는 세션 저장소에 저장된 세션 정보와 사용자가 제공하는 정보가 일치하는지 확인하는 방식이다

세션 기반 자격 증명의 특징

• 세션은 인증된 사용자 정보를 서버 측 세션 저장소에서 관리한다
• 생성된 사용자 세션의 고유 ID인 세션ID는 클라이언트의 쿠키에 저장되어 Request 전송 시, 인증된 상요자인지를 증명하는 수단으로 사용된다.
• 세션 ID만 클라이언트 쪽에서 사용하므로 상대적으로 적은 네트워크 트래픽을 사용한다
• 서버측에서 세션 정보를 관리하므로 보안성 측면에서 더 유리하다
• 서버의 확장성 면에서는 세션 불일치 문제가 발생할 가능성이 높다
• 세션 데이터가 많아질수록 서버의 부담이 가중될 수 있다
• SSR(Server Side Rendering)방식의 애플리케이션에 적합한 방식이다

토큰 기반 자격 증명 방식

일상 생활에서의 토큰은 일종의 출입카드에 비교될 수 있다. 빌딩에 방문했을 때 ,1층 로비 안내 데스크에서 임시 출입카드를 발급해주는 상황이라면 안내 데스크 직원의 요청에 따라 방문자 목록에 신원정보를(이름, 번호, 목적 등)입력하고 임시 출입카드를 받는다

여기서 신원정보는 자신을 증명하는 자격 증명 정보(Credential)에 비유될 수 있고, 임시 출입 카드는 인증된 자신을 증명하는 토큰에 비유 될 수 있다. 그런데 발급 받은 임시 출입 카드로 빌딩 내에 있는 모든 장소의 출입문을 열수없다 이처럼 애플리케이션에서 사용되는 토큰 역시 인증된 사용자의 자격을 증명하는 동시에 접근 권한을 부여해 접근 권한이 부여된 특정 리소스에만 접근이 가능하게 하는 역할을한다

토큰 기반 자격 증명 방식의 특징

• 토큰에 포함된 인증된 사용자 정보는 서버 측에서 별도의 관리를 하지 않는다
• 생성된 토큰을 헤더에 포함시켜 request 전송시, 인증된 사용자인지를 증명하는 수단으로 사용된다
• 토큰내에 인증된 사용자 정보 등을 포함하고 있으므로 세션에 비해 상대적으로 많은 네트워크 트래픽을 사용한다
• 기본적으로 서버 측에서 토큰을 관리하지 않으므로 보안성 측면에서 더 불리하다
• 인증된 사용자 request의 상태를 유지할 필요가 없기 때문에 서버의 확장성 면에서 유리하고, 세션 불일치 같은 문제가 발생하지 않는다
• 토큰에 포함되는 사용자 정보는 토큰의 특성상 암호화가 되지 않기때문에 공격자에게 토큰이 탈취될 경우, 사용자 정보를 그대로 제공하는 셈이된다. 따라서 민감한 정보는 토큰에 포함시지 말아야한다
• 토큰이 만료되기 전까지는 토큰을 무효화 시킬 수 없다
• CSR(Client Side Rendering) 방식의 애플리케이션에 적합한 방식이다.

세션의 경우 서버 확장시, 세션 불일치 문제가 발생할 수 있지만 Sticky Session, Session Clustering, Session 저장소의 외부 분리 등의 작업을 통해 보완을 하고 있다

토큰의 경우 기본적으로 토큰 무효화를 할 수 없지만 key/value 쌍의 형태로 저장되는 Redis 같은 인메모리 DB에 무효화 시키고자 하는 토큰의 만료 시간을 짧게 주어 해당 토큰을 사용하지 못하게 하는 등의 방법을 사용해 토큰 무효화 문제를 보완하고 있다.

 

Point

• 세션 기반 자격 증명 방식은 서버 측에 인증된 사용자의 정보를 세션 형태로 세션 저장소에 저장 하는 방식이다.
• 세션 기반 자격 증명의 특징
  • 세션은 인증된 사용자 정보를 서버 측 세션 저장소에서 관리한다.
  • 생성된 사용자 세션의 고유 ID인 세션 ID는 클라이언트의 쿠키에 저장되어 request 전송 시, 인증된 사용자인지를 증명하는 수단으로 사용된다.
  • 세션 ID만 클라이언트 쪽에서 사용하므로 상대적으로 적은 네트워크 트래픽을 사용한다.
  • 서버 측에서 세션 정보를 관리하므로 보안성 측면에서 조금 더 유리하다.
  • 서버의 확장성 면에서는 세션 불일치 문제가 발생할 가능성이 높다.
  • 세션 데이터가 많아지면 질수록 서버의 부담이 가중될 수 있다.
  • SSR(Server Side Rendering) 방식의 애플리케이션에 적합한 방식이다.
• 토큰 기반 자격 증명 방식은 인증된 사용자의 정보를 토큰에 저장하고, 접근 권한을 부여해 접근 권한이 부여된 특정 리소스에만 접근이 가능하게 하는 방식이다.
• 토큰 기반 자격 증명의 특징
  • 토큰에 포함된 인증된 사용자 정보는 서버 측에서 별도의 관리를 하지 않는다.
  • 생성된 토큰을 헤더에 포함시켜 request 전송 시, 인증된 사용자인지를 증명하는 수단으로 사용된다.
  • 토큰내에 인증된 사용자 정보 등을 포함하고 있으므로 세션에 비해 상대적으로 많은 네트워크 트래픽을 사용한다.
  • 기본적으로 서버 측에서 토큰을 관리하지 않으므로 보안성 측면에서 조금 더 불리하다.
  • 인증된 사용자 request의 상태를 유지할 필요가 없기 때문에 서버의 확장성 면에서 유리하고, 세션 불일치 같은 문제가 발생하지 않는다.
  • 토큰에 포함되는 사용자 정보는 토큰의 특성상 암호화가 되지 않기때문에 공격자에게 토큰이 탈취될 경우, 사용자 정보를 그대로 제공하는 셈이 되므로 민감한 정보는 토큰에 포함시키지 말아야 한다.
  • 기본적으로 토큰이 만료되기 전까지는 토큰을 무효화 시킬 수 없다.
  • CSR(Client Side Rendering) 방식의 애플리케이션에 적합한 방식이다.