세션 기반 인증과 토큰 기반 인증 (JWT)

인증과 인가

인증 Authentication

클라이언트가 요청한 자신의 정보와 사용자가 맞는지 검증하는 과정이다.

즉, 로그인이다.

 

인가 Authorization

인증 작업 후 이뤄지는 작업으로, 인증된 사용자에 대한 자원 접근 확인 절차를 의미한다.

 

예를 들어, 

USER1 은 글 작성, 조회, 수정, 삭제 등 일반적인 작업에 대한 권한이 부여되어 있다. 

하지만 USER1 은 USER2가 작성한 글을 수정하거나 제거할 수는 없다. 

타 유저의 리소스에 대해서는 인가되어 있지 않기 때문이다.

 

 

HTTP의 비상태성(Stateless)

HTTP는 비상태성이라는 특성을 갖는다. 

서버는 클라이언트의 상태를 저장하지 않으며, 따라서 이전 요청과 다음 요청의 맥락이 이어지지 않는다.

즉, HTTP 단독으로는 요청한 클라이언트가 이전에 이미 인증과정을 거쳤는지 알 수 없다.

이러한 상태라면 사용자가 글을 조회하거나 작성할 때 마다 로그인을 요청할 수 밖에 없다.

 

브라우저에 아이디와 패스워드를 저장하고, 매 요청마다 함께 해당 정보를 보내는 방법은 전송 데이터가 커져 비효율 적이고, 클라이언트에 민감한 데이터가 그대로 저장되어 보안에도 굉장히 취약하다.

 

이러한 문제점을 해결하기 위해 세션 또는 토큰을 사용한다.

 

세션기반 인증

사용자의 인증 정보가 서버의 세션 저장소에 저장되는 방식이다. 

1. 사용자가 로그인을 하면,

2. 해당 인증 정보를 서버의 세션 저장소에 저장하고,

3. 사용자에게는 저장된 세션 정보의 식별자인 Session ID를 발급한다.

 

발급된 Session ID는 브라우저에 쿠키 형태로 저장되지만, 실제 인증 정보는 서버에 저장되어 있다.

 

브라우저는 인증 절차를 마친 이후의 요청마다 HTTP Cookie 헤더에 Session ID 를 함께 서버로 전송한다.

서버는 요청을 전달받고, Session ID에 해당하는 세션 정보가 세션 저장소에 존재한다면 해당 사용자를 인증된 사용자로 판단한다.

 

토큰기반 인증 (JWT)

세션 기반 인증이 인증 정보를 서버에 저장하는 방식이라면,

토큰 기반 인증은 인증 정보를 클라이언트가 직접 들고 있는 방식이다. 

인증 정보가 토큰의 형태로 브라우저의 로컬 스토리지(혹은 쿠키)에 저장된다. 

대표적인 토큰인 JWT의 경우 디지털 서명이 존재해 토큰의 내용이 위변조 되었는지 서버측에서 확인할 수 있다.

 

사용자가 가지고 있는 토큰을 HTTP 의 Authorization 헤더에 실어 보낸다.

서버는 토큰이 위변조 되었거나, 만료 시각이 지나지 않은지 확인한 이후 토큰에 담겨있는 사용자 인증 정보를 확인해 사용자를 인가한다.

 

 

JWT

Json Web Token 의 줄임말로, 

JSON 형식을 사용하여 통신 양자간의 정보를 안전하게 전송한다.

JWT는 정보가 토큰 자체에 포함된 (Self-Contained) 클레임 (Claim) 기반 토큰이다.

 

일반적으로 인증과 권한부여에 사용된다.

1. 인증 절차를 거쳐 서버에서 JWT 를 발급해주면,

2. 클라이언트는 이를 보관하고 있다가 API 등을 사용할 때에 서버에 JWT를 함께 제출하며

3. 서버로부터 행위에 대해 인가를 받는다.

 

JWT는 해시 혹은 비대칭키 방식을 사용하여 서명하기 때문에 무결성을 검증할 수 있다는 특징이 있다.

토큰 자신이 정보를 직접 포함하고 있어 통신 양자간 정보를 안전하게 전송할 때에도 사용된다.

또한, URL에 대해 안전한 (URL-Safe) 문자열로 구성되어 있어 어떤 경로로든 전송할 수 있다.

 

 

차이점

사이즈

세션 

• Cookie 헤더에 세션 ID만 실어 보내면 되므로 트래픽을 적게 사용

토큰

• 세션 방식보다 훨씬 더 많은 네트워크 트래픽을 사용
  • 토큰의 ID, 사용자 인증 정보와 토큰의 발급시각, 만료시각 정보가 들어가 있기 때문

 

안전성 및 보안

세션 

• 모든 인증 정보를 서버에서 관리하기 때문에 안전한 편
  • 세션 ID가 탈취되어도 서버측에서 해당 세션을 무효 처리하면 된다.
  • 모든 데이터가 서버에 저장되기 때문에 아무나 함부로 열람할 수 없음

 

토큰

• 클라이언트가 모든 인증정보를 가지고 있으므로 안전에 취약함
  • 탈취된다면 해당 토큰이 만료되기 전까지 피해를 입을 수 있음
  • JWT에 실린 Playload가 별도로 암호화 되어 있지 않으므로 누구나 내용을 확인할 수 있음

 

확장성

최근 웹 어플리케이션이 토큰 기반 인증을 사용하는 이유는 확장성때문이다.

 

세션 

웹 어플리케이션의 서버 확장 방식은 수평 확장을 사용한다. 

즉, 한대가 아닌 여러대의 서버가 요청을 처리하게 된다. 

이때 별도의 작업을 해주지 않는다면, 세션 기반 인증 방식은 세션 불일치 문제를 겪게 된다.

이를 해결하기 위해서 Sticky Session, Session Clustering, 세션 스토리지 외부 분리 등의 작업을 해주어야한다.

 

토큰

서버가 직접 인증 방식을 저장하지 않고, 클라이언트가 저장하는 방식을 취하기 때문에 세션 불일치 문제로부터 자유롭다. 

토큰 기반 인증 방식은 HTTP의 비상태성(Stateless)를 그대로 활용할 수 있고, 따라서 높은 확장성을 가질 수 있다.

 

서버의 부담

세션

• 서비스가 세션 데이터를 직접 저장 및 관리
  • 세션 데이터의 양이 많아지면 많아질수록 서버의 부담 증가

토큰

• 클라이언트가 인증 데이터를 직접 가지고 있음
  • 유저의 수가 얼마나 되던 서버의 부담이 증가하지 않음
  • 서버 측면에서 토큰 기반 인증 방식이 좀 더 유리할 수 있음