1. JWT의 장점

• 세션은 별도의 저장소가 필요하다. 따라서 서버를 확장하거나 유지/보수할 때 고려해야할 게 많아지는 대신(Sticky Session) JWT는 그러한 것을 신경쓰지 않고 확장할 수 있다.
• 세션은 서로 다른 도메인 간에는 공유될 수 없다.

2. JWT의 단점

• 이미 발급된 JWT는 돌이킬 수 없다. JWT는 한번 발급되면 유효기간이 완료될 때까지는 계속 사용할 수 있다. 이에 대한 해결책으로 Access Token의 유효기간을 짧게 하고 Refresh Token을 줄 수도 있지만 완벽하게 이 문제를 해결할 수는 없다.(그런데 어차피 세션도 세션 키가 노출되면 개발자가 정한 세션 유효기간 안에서는 계속 사용할 수 있어서 이건 둘다 똑같은 거 아닌지..) 하지만 세션의 경우 뭔가 낌새가 이상하면 바로 세션을 메모리에서 없애면 되지만 JWT는 그렇게 할 수 없기는 하다.

3. JWT의 구성 요소

(1) Header

토큰의 종류, 사용된 서명 알고리즘 등을 담고 있음
예시)

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

Base64 인코딩된다.

(2) Payload

사용자에 대한 정보를 의미하는 Claim들을 담고 있음, Claim의 종류에는 크게 세 가지가 있음

a. Registerd claim

필수는 아니지만 정보를 두는 것이 recommended되는 것들

iss(issuer)
expr(expiration time)
sub(subject)
aud(audience)
...

*JWT는 용량을 줄이기 위해 Registerd claim 이름들이 모두 3글자이다.

b. Public claim

These can be defined at will by those using JWTs. But to avoid collisions they should be defined in the IANA JSON Web Token Registry or be defined as a URI that contains a collision resistant namespace.

c. Private claim

These are the custom claims created to share information between parties that agree on using them and are neither registered or public claims.

Payload 부분도 Base64 인코딩된다.

(3) Signature

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

*알고리즘은 HMACSHA256이 아닌 다른 것으로 달라질 수도 있다.(RSA, ESDSA 공개키/개인키 기반으로 정보 교환용으로 JWT는 사용될 수 있다.)

이러한 Signature 부분은 메시지가 통신 도중 변조되지 않았고, private key로 서명된 경우에는 JWT Sender가 JWT에 드러난 자신이라는 것을 증명한다.

그리고 최종 JWT의 모양은

Encoded Header.Encoded Payload.Signature 

이다. 각 부분 사이에 점을 붙인다.

4. 실제로 JWT 넣는 곳

서버에서 보내줄 때는

HTTP/1.1 200 OK
Set-Cookie: access_token=abc~; Path=/; Domain=bar.com; expires=Thu, 01 Jan 2050 00:00:00 GMT;
...

이런 식으로 리스폰스의 바디에 담아서 보내준다. 그리고 이렇게 토큰을 받은 클라이언트는

...
Authorization: Bearer <token>
...

리퀘스트의 헤더에 Authorization 헤더를 두고, 거기 부분에 넣어서 서버로 보낸다.

로그아웃할 때는 서버에서

Set-Cookie: access_token=''; Path=/;

이런 식으로 비워서 보내준다.

5. JWT 저장 장소

(1) Cookie

(2) LocalStorage

(3) SessionStorage