JWT 란?

1. JWT는 Authorization을 위한 것이다. Authentication을 위한 것이 아니라. 

- Authenticate는 유저네임과 패스워드를 받아서 이게 맞는지 확인하는 것을 말하는 것이다. (로그인 하는 것을 생각)

- Authorization은 지금 요청하는 사람이 어떤 리소스에 접근이 가능한지를 verify 하는 것이다. 

 

 

2. 원래 Authorization을 위해서는 Session을 사용했다.

로그인할때(Authentication할때), response에 set-cookie헤더를 사용해서 Session id를 보내놓고, User가 요청할때, 무조건 session id쿠키를 같이 보내서, 이 쿠키값이 서버의 메모리든 뭐든에 저장되어있던 session 값과 일치하는지 확인하고, 이 user가 리소스에 접근을 해도 되는지 파악한다(Authoriaztion)

 

 

3. JWT는 쿠키를 써서 처리하지 않고, JSON web Token을 Authorization을 위해 사용하는 것이다. 

 

4. JWT는 세가지로 구성되어있다(개미의 머리가슴배처럼). 

 

JWT는 . 으로 각 부분이 구분되어있는데, 서버에서 생성한 JWT의 첫부분은 Header이고, 두번째 부분은 데이터 부분이다. 여기에 User의 정보를 바로 넣어둔다.

 

헤더는 아래와 같이 생겼고 해당 내용을 Base64Url로 인코딩한다(암호화 아님)

{
  "alg": "HS256",
  "typ": "JWT"
}

 

 

 payload는 아래와 같이 생겼고 이것도  Base64Url로 인코딩한다(암호화 아님)

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

 

 

Signature부분은 앞의 두가지 헤더, payload값과 서버의 시크릿 키를 가지고 HMAC SHA256 algorithm 같은것을 적용해서 암호화한 갓이다.

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

 

이제 앞의 세가지 값 Header + Payload + Signature을 연결해서 보내놓으면 클라이언트에서 앞의 두가지(헤더, 유저)값을 가지고 장난질을 치면 Authoriaztion 할때 마지막 Signature값으로 변했단걸 바로 알아버린다. 

 

 

5. 사용할때!!

Session는 두서비스가 공유하지 않아서, 자연스럽게 로그인이 어려운데,

JWT는 서버가 key만 공유한다면 사용자가 두 서비스에 접근 가능하다

 

 

 

참고자료

jwt.io/introduction

JWT.IO

 

www.youtube.com/watch?v=7Q17ubqLfaM&ab_channel=WebDevSimplified