JWT

구조
동작 방식
참고자료
이 문서를 인용한 문서

RFC 7519
토큰 기반 인증 방식. 서버의 무상태성, 확장성, 보안성을 확보할 수 있다.

구조

Header, Payload, Signature 세 부분으로 구성됨.
세 부분은 .으로 구분한다. (xxxxx.yyyyy.zzzzz)

토큰의 타입, 서명 알고리즘 정보를 포함하는 JSON 포맷:
```
{
  "alg": "HS256",
  "typ": "JWT"
}
```
Base64Url로 인코딩되어 JWT의 첫 번째 부분으로 들어간다.

Payload

페이로드는 클레임들을 가진 JSON 포맷:

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

클레임은 엔티티(유저)와 추가적인 데이터에 대한 상태.
세 가지 종류의 클레임이 있다:
- registered claims: 필수는 아니지만 권장된다:
  - iss(issuer)
  - exp(expiration time)
  - sub(subject)
  - aud(audience)
  - others
- public claims: URI 형식으로 충돌이 방지된 이름을 가져야 한다.
- private claims: 커스텀 클레임. 양측 사이에 합의된 이름을 사용한다.
Base64Url로 인코딩되어 JWT의 두 번째 부분으로 들어간다.

Signature

인코딩된 헤더와 페이로드, 시크릿을 헤더에 명시된 서명 알고리즘으로 인코딩한 문자열:
```
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
```
Base64Url로 인코딩되어 JWT의 세 번째 부분으로 들어간다.

합치기

헤더, 페이로드, 시그니처를 .을 구분자로 모두 합치면 하나의 JWT가 된다.

동작 방식

기존 서버 기반 인증의 경우 서버가 세션 정보를 들고 있어야 했다:
sequenceDiagram participant S as Server participant C as Client S->>C: 웹 페이지 C->>S: 로그인 요청 Note left of S: 세션 생성 S->>C: 로그인 응답 C->>S: 요청 Note left of S: 세션 저장소 조회 S->>C: 응답
토큰 기반으로 인증하면 서버가 토큰의 유효성만 검증한다:
- 클라이언트가 서버의 보호된 자원에 접근하려면 요청에 JWT를 담아 보낸다:
```
Authorization: Bearer <token>
```
- 서버는 요청의 Authorization 헤더에 담긴 JWT의 유효성을 검증하고 응답한다.
sequenceDiagram participant S as Server participant C as Client S->>C: 웹 페이지 C->>S: 로그인 요청 Note left of S: 토큰 생성 S->>C: 로그인 응답 Note right of C: 토큰 저장 Note right of C: 토큰 읽기 C->>S: 토큰과 함께 요청 Note left of S: 토큰 검증 S->>C: 응답

참고자료

이 문서를 인용한 문서

주제문서