JWT

해당 포스트는 인프런의 "Spring Boot JWT Tutorial"을 보고 작성되었습니다.

JSON Web Token

-> JSON 객체를 사용해 클라이언트와 서버, 서비스와 서비스 사이 통신 시 권한 인가(Authorization)를 위해 토큰 자체에 정보를 저장하고 있는 'Web Token'이다.

JWT 구조

{
  "alg" : "HS512"
}

• Head : Signature를 해싱하기 위한 알고리즘과 토큰 타입으로 구성되어있다.

{
  //등록된 클레임
  "sub" : "jennyfromdeblock"
  //비
  "auth" : "ROLE_USER"
  "exp" : 1234567890
}

• Payload : 서버와 클라이언트가 주고받는 시스템에서 실제로 사용될 정보에 대한 내용을 담고있다. 이러한 내용을 정보의 조각을 '클레임(claim)'이라고 부르고, 크게 등록된 클레임, 공개 클레임, 비공개 클레임 총 3가지로 나누어져 있다.

-> 등록된 클레임은 토큰 정보를 표현하기 위한 이미 내용이 있는 데이터들이다. 항상 Key와 Value형식으로 이루어지고, 이 Key값은 간결하게 3글자로 이루어져있다.
-> 공개 클레임은 충돌 방지를 위해 URI 형식으로 작성되어야 한다.
-> 비공개 클레임은 사용자가 정의한 값으로, 클라이언트와 서버 협의하에 사용될 클레임이다, 이름이 중복되어 충돌될 수 있다.

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

• Signature : 서버에서는 이 Signature 부분을 통해 해당 토큰이 유효한 토큰인지 아닌지 구분 할 수 있는 역할을 한다. 보통은 헤더값과 페이로드 값을 Base64로 인코딩을 하고, 이 인코딩한 값을 헤더에서 정의한 알고리즘으로 해싱하여 이 값을 다시 base64로 인코딩하여 생성된 것이 Signature부분이다.

JWT의 장점

• 무엇보다 중앙 인증 서버와 데이터 스토어에 대한 의존성이 없어 MSA 같이 시스템의 수평 확장 등에 유리하다.
• Base54 URI safe Encoding을 이용하기 때문에, URL, 쿠키, 헤더 어디에서든 사용할 수 있는 범용성을 갖고있다.
• 독립적이며, 토큰 만료 기능이 내장되어 있다.

JWT의 단점

• Payload에 저장하는 정보가 많아지면 트래픽 사이즈가 커진다.
• 그에따라 데이터를 설계해야하는 부분도 고려해야한다.
• 토큰이 서버에 저장되는게 아닌 클라이언트에 저장되기 때문에 서버나 DB에서는 각 클라이언트에 저장된 토큰 정보를 조작 할 수 없다.