JWT

그동안 프로젝트를 진행하며, 생각없이 jsonwebtoken 패키지를 사용했다.

이 과정에서 JWT가 정확히 어떤 일을 하는지에 대한 인지 없이 사용을 했고, 왜 써야하는지에 대한 명확한 이유가 없었다.

그저 쓰던거니까 라는 생각으로, 무지성으로 사용할 수는 없으니 이번 기회에 정리해보기로 한다!

 

JWT란?

JWT는 JSON 형태로 통신 시 권한을 확인하기 위해 사용하는 토큰이다.

그동안 Header에 추가해서 사용했었는데 JWT는 URL-safe라는 특징을 가지고 있으며, 이는 인코딩 없이도 URL에 사용이 가능한 문자열로만 구성되어있음을 의미한다.

 

JWT 프로세스를 간단하게 표현하면 아래와 같다! :)

 

 

JWT 구조

JWT는 Header, Payload, Signature로 구성되며, 각 부분은 점(.)으로 구분된다.

 

 

Header

헤더는 JWT를 어떻게 검증하는 지에 대한 내용을 담고 있으며, 토큰 유형과 사용 중인 서명 알고리즘의 두 부분 으로 구성된다.

{
  "alg": "HS256", // 서명 시 사용하는 알고리즘
  "typ": "JWT", // 토큰 유형
  "kid": "Key ID" // (선택) 서명 시 사용하는 키를 식별하는 값이다.
}

 

kid에 대한 상세한 설명

위의 JSON은 Base64 URL Safe 형태로 인코딩 되며, JWT의 첫 번째 부분인 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IktleSBJRCJ9 가 된다.

Base64와 Base64 URL Safe의 차이 : Base64 URL Safe는 Base64의 문자 중 URL에서 의미가 존재하는 '+', '/'를 '-', '_'으로 대체한다.

 

Payload

JWT의 본문에 해당한다. 페이로드에 있는 각 속성들은 Claim Set이라고 부르며, 클라이언트와 서버간 통신에 필요한 값들로 구성된다.

{
  "name": "고우혁",
  "admin": true,
  "iat": 1635839022
}

일반적으로 사용되는 값
iss :발급자
iat : 발급 시간
exp : 만료 시간
sub : 제목 
aud : 대상

페이로드 역시 Base64 URL Safe 형태로 인코딩 되며, JWT의 두 번째 부분인 eyJuYW1lIjoi6rOg7Jqw7ZiBIiwiYWRtaW4iOnRydWUsImlhdCI6MTYzNTgzOTAyMn0 가 된다.

 

Signature

인코딩된 헤더와 페이로드를 합친 문자열을 서명한 값이며, 헤더에 지정된 알고리즘을 사용한다.

 

 

그래서 프로젝트에 사용한 이유는?

 

세션과 쿠키를 이용하면 해당 값을 기준으로 데이터베이스에서 사용자를 식별하기 위해 세션에 해당하는 데이터를 메모리 또는 데이터베이스에 저장해야 한다.

jwt는 토큰 자체에 사용자에 대한 정보가 저장되어 있고, 해당 정보로 사용자를 식별하게 된다.

그러므로 상태를 저장하기 위한 추가적인 처리가 필요하지 않다.

또한, 사용이 익숙했기에 2주라는 짧은 기간의 프로젝트에서 사용하기에 매우 적합했다는 판단도 있었다.

 

하지만 이번에 정리하면서 찾아보니 사용자의 상태가 변화하더라도 토큰은 만료될 때 까지 유효하다는 문제점이 있었다.

jwt의 표준은 stateless이기 때문에 사용자가 비밀번호를 바꾼다거나, 로그아웃 등이 발생해도 토큰은 유효해야 한다.

페이로드에 검증을 위한 클레임을 담아 서버에서 추가적인 검증을 하는 방법으로 처리할 수 있지만 이 경우 표준을 위반하게 되는 셈.