JWT 를 간단히 정리해보자

 

 

JWT (JSON Web Token) 란?

 

JSON 객체로 정보를 안전하게 전송하기 위한 방법

웹 토큰에 정보를 담아 사용자에게 권한을 부여하거나, 정보를 교환할 때 사용할 수 있다.

 

 

 

JWT를 왜 사용할까?

 

우리가 주로 사용하는 REST API는 HTTP 프로토콜을 기반으로 서비스된다.

http는 stateless 해서 상태를 저장하지 않는다.  *자세한 내용은 아래 포스팅 참조

https://e-una.tistory.com/47

[Network] Socket 과 HTTP 프로토콜

 

하지만 실제 서비스에서 사용자 권한 부여와 같은 기능은 상태를 저장할 수 밖에 없는데

기존에는 이를 session이나 session cluster를 통해 보완해왔다. 

 

만약 회사 웹페이지에 접속하는 사용자가 많아져

scale out(수평 확장, 로드밸런서 뒤에 새 서버를 추가하는 것)을 한다고 가정해보자.

 

session clustering 을 사용한다면? 모든 서버에 동일한 세션 정보를 저장해야 한다.

redis와 같은 인메모리 디비를 도입한다면? 레디스용 서버를 여러 대 구입해야 한다.

 

이러한 단점에 의해 HTTP의 stateless 철학에 맞는 방식인 JWT를 선택하게 되는 것이다.

 

 

 

JSON Web Token 의 구조

 

- Header

Signature 해싱을 위한 알고리즘 정보

 

{
  "alg": "HS256", // 주로 HS256나 RS256 알고리즘이 사용된다.
  "typ": "JWT"
}

 

위와 같은 JSON은 Base64 URL 인코딩되어 JWT의 첫 부분이 된다.

 

 

- Payload

JWT 의 두 번째 파트로 클레임을 포함하고 있다.

클레임이란 일반적으로 유저와 같은 엔티티 정보나 그 외 추가적인 정보를 담고있다.

서버와 클라이언트가 주고받는 실제 정보 부분인 것!

 

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

 

- Signature

토큰의 유효성 검증을 위한 문자열

메시지가 도중에 변경되지 않았는지 확인하는 데 사용된다.

 

// 인코딩된 헤더, 인코딩된 페이로드, 비밀, 헤더에 지정된 알고리즘을 가져와 사용
HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

 

 

여기까지 Security 와 붙이기 전에 JWT에 대해 간단히 정리해보았다.