JSON Web Token(JWT)이란?

Session 기반 인증

기존의 시스템에서는 Session 기반의 인증 방식을 사용했습니다. 사용자가 로그인을 하면, 이에 대한 인증 정보를 서버에 저장하게되는데 이 것을 Session이라고 부릅니다. 인증 정보를 서버에 저장하기때문에 stateful한 인증 방식이라고 합니다.

Session의 제약

서버 기반의 인증은, 사용자로부터 요청을 받으면 사용자의 인증 정보를 유지하기 위해 세션을 유지해야합니다. 일반적으로 세션은 메모리에 저장하거나, 서버의 부하를 방지하기 위해서 데이터베이스에 저장하기도 합니다. 트래픽이 많은 경우, 서버 또는 데이터베이스에 부하를 줄 수 있으며, 이를 해결하기 위해 서버를 확장하거나 세션을 분산할 수 있는 시스템을 구축해야합니다.  예를 들어, 인증을 처리하는 서버가 분산되어있다면 사용자가 로그인 했던 서버에서만 요청을 받도록 설정을 해야합니다. 이러한 과정은 번거롭고 복잡할 수 있습니다.

 

Token 기반 인증(JSON Web Token)

Session 기반의 인증의 제약적인 부분을 보완한 인증 방식이 token 기반의 인증입니다. 사용자가 로그인을 하면, 인증에 성공한 사용자에게 토큰을 발급합니다. 이후 사용자는 http 요청 header에 토큰을 담아서 서버에 요청을 보내면, 서버는 토큰으로 인증을 하게됩니다. 인증 정보를 서버에 저장하지 않으며 사용자 요청의 토큰만으로 인증을 진행하기 때문에 stateless한 인증방식이라고 합니다.

Session 기반의 인증 방식을 보완

토큰은 클라이언트에 저장이됩니다. 따라서 서버는 사용자의 인증에 대해서 알 필요가 없으며, 이러한 점은 서버 확장에 유리합니다.

Json Web Token이란?

SON Web Token,은 선택적 서명 및 선택적 암호화를 사용하여 데이터를 만들기 위한 인터넷 표준으로, 페이로드는 몇몇 클레임(claim) 표명(assert)을 처리하는 JSON을 보관하고 있다. 토큰은 비공개 시크릿 키 또는 공개/비공개 키를 사용하여 서명된다. -- 위키피디아

Json Web Token 구성

이미지 출처: https://supertokens.com/static/b0172cabbcd583dd4ed222bdb83fc51a/9af93/jwt-structure.png

JWT는 Header, Payload, Signature로 구성되어있으며, 각 부분은 comma(.)로 구분되어 연결됩니다.  각 부분은 JSON 형태이며 Base64Url로 인코딩되어있습니다. 

Header

typ, alg 두가지 정보로 구성됩니다.

• type: 토큰의 타입을 지정합니다.
• alg: signature를 이용한 토큰 검증에 사용하는 알고리즘 방식을 지정합니다.

{
  "alg": "HS256", // SHA256, RSA등
  "typ": JWT
}

Payload 

토큰에서 사용하는 정보의 조각인 Claim이 담겨있습니다. Claim은 Registered Public Claim, Private Claim 총 3가지로 나뉘며, JSON 형태로 구성됩니다.

Signature

토큰을 encoding 하거나 decoding하여 인증시, 사용하는 고유한 암호화 코드입니다.

Signature는 Header, Payolad의 값을 Base64Url로 인코딩 한 뒤, secret key를 이용하여 앞서 인코딩한 값을 Header에서 정의한 알고리즘으로 해싱을 하고, 이 값을 다시 Base64Url로 인코딩하여 생성합니다.

 

Header에 JWT 추가

클라이언트가 서버에 요청을 할 때, 일반적으로 Bearer 스키마를 사용하여 Authorization 헤더 안에 JWT를 보냅니다

{
  "Authorization": "Bearer {TOKEN}"
}

Json Web Token의 제약 및 주의 사항

• 토큰의 길이가 길기때문에 인증 요청이 많아질수록 네트워크에 부하를 줄 수 있습니다.
• Payload는 Base64Url로 인코딩된 값이므로, Payload를 탈취하여 decoding하면 데이터를 확인할 수 있습니다. 따라서 Payload에 중요 데이터를 넣지말아야합니다.
• JWT는 토큰의 상태를 저장하지 않기때문에 한번 생성된 토큰을 제어할 수 없습니다. 따라서 refresh token, sliding session등으로 만료 시간을 필수로 설정해야합니다.

Refresh Token

JWT 발급시, Access Token은 보안상의 이유로 짧은 만료시간을 가지고 있습니다. 따라서 사용자는 토큰이 만료되면 재로그인을 해서 Access Token을 새로 발급받아야합니다. 이러한 문제를 Refresh Token을 이용하여 개선할 수 있습니다.

 

Access Token 발급시, Refresh Token을 함께 발급합니다. Refresh Token은 Access Token 재발급하기 위한 토큰으로, Access Token은 짧은 만료 시간을 부여하고(ex. 1분) Refresh Token은 긴 만료시간을 부여합니다.(ex. 일주일)

Access Token이 만료되면, 서버에서는 토큰이 만료되었다는 응답을 보냅니다. 이러한 응답을 받으면 클라이언트에서는 Access Token과 함께 발급받은 Refresh Token을 서버로 보냅니다. 서버는 Refresh Token의 유효성을 검증하고, 유효한 토큰이면 새로운 Access Token을 발급합니다.