[Server] JWT(Json Web Token) 란?

jinni·2022년 12월 6일

JWT는 인증에 필요한 정보를 암호화시키는 토큰이며, Json포맷을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 Web Token 이다.

사용자는 Access Token을 HTTP 헤더에 실어 서버로 보낸다. JWT는 토큰 자체를 정보로 사용하는 Self-Contained 방식으로 정보를 전달한다.

Self-Contained(자가 수용적)란?
JWT는 필요한 모든 정보를 자체적으로 지니고 있다. JWT 시스템에서 발급된 토큰은 토큰에 대한 기본 정보, 전달 할 정보, 토큰이 검증됐다는 것을 증명해주는 서명을 포함하고 있다. → 토큰 자체에 정보를 담고 있어서 위험할 수도 있다.

JWT의 구조를 알아보자!

출처: https://www.hahwul.com/2016/01/web-hacking-jwtjson-web-token-jwt-test.html

`Header`

type : 토큰 타입 지정
alg: 알고리즘 방식 지정, 서명(signature) 및 토큰 검증에 사용

`Payload`

토큰에서 사용할 정보의 조각들인 클레임(claim)이 담겨있다. -> 일반적으로 유저 별 고유 ID 값, 유효기간 (Expired) 등이 들어있다. 클레임의 종류는 3가지가 존재한다.

클레임의 종류는 뭐가 있는데? 🙄

1. 등록된 클레임 (Register Claim)

등록된 클레임은 토큰 정보를 표현하기 위해 이미 정해진 종류의 데이터 들로 모두 선택적으로 작성이 가능하며 사용할 것을 권장. 또한, JWT를 간결하게 하기 위해 key는 모두 길이 = 3 의 String이다. 이 중 subject로는 unique한 값을 사용하는데, 주로 사용자 이메일을 사용한다.

iss: 토큰 발급자(issuer)
sub: 토큰 제목(subject)
aud: 토큰 대상자(audience)
exp: 토큰 만료시간(expiration) -> NumericDate 형식으로 되어있어야 한다. (ex - 1970-01-01T00:00:00Z UTC 지정된 UTC 날짜/시간까지)
nbf: 토큰 활성 날짜(not before) → 이 날이 지나기 전의 토큰은 활성화되지 않음.
iat: 토큰 발급 시간(issued at) → 토큰 발급 이후의 경과 시간을 알 수 있음.
jti: JWT 토큰 식별자(JWT ID) → 중복 방지를 위해 사용, 일회용 토큰(Access Token) 등에 사용

2. 공개 클레임 (Public Claim)

공개 클레임은 사용자 정의 클레임으로 공개용 정보를 위해 사용된다. 충돌 방지를 위해 URI 포맷을 이용하며 예시는 아래와 같다. (공개되어도 무방한 정보 정의)

{
		"본인 블로그 URL": true
}

3. 비공개 클레임 (Private Claim)

비공개 클레임은 사용자 정의 클레임으로 서버와 클라이언트 사이에 임의로 지정한 정보를 저장한다. 아래의 예시와 같다.

{
		"token_type": access
}

`Verify Signature(서명)`

토큰을 인코딩하거나 유효성 검증을 할 때, 사용하는 고유한 암호화 코드이다. 서명은 위에서 만든 헤더와 페이로드의 값을 각각 BASE64Url로 인코딩하고, 인코딩한 값을 비밀 키를 이용해 헤더에서 정의한 알고리즘으로 해싱을 진행한 뒤, 이 값을 다시 BASE64Url로 인코딩하여 생성한다.

생성된 토큰은 HTTP 통신 시, Authorization 이라는 key의 value 로 사용된다. 일반적으로 value 에는 Bearer 이 붙는다.

{
		"Authorization": "Bearer {생성된 토큰 값}"
}

최종적인 결과는 구조에서 나타나는 모습의 형태로 된다.

Header, Payload는 따로 암호화되지 않고 인코딩만 되기 때문에 누구나 디코딩할 수 있다. 즉, Payload에 비밀번호 같은 중요 정보가 들어갈 경우, 쉽게 노출될 수 있다.

그러나, Verify Signature는 SECRET KEY를 알지 못 하면, 복호화할 수 없다.

JWT의 장단점은 뭔데?

장점

트래픽 부담 낮음
사용자 인증에 필요한 모든 정보는 토큰 자체에 포함 -> 별도의 인증 저장소가 필요없음. 따라서, 서버 부하가 걸릴 일이 적다.
내장된 만료
만료 기간을 정해놓아 관리 용이
독립적인 JWT
클라이언트 누구든지 HTTP request 를 생성할 수 있다면, 서버로 요청할 수 있다. (stateless(무상태성) → connection 등의 상태 정보 저장X)

단점

필드가 추가되면 될 수록 토큰이 커진다. (세션/쿠키 방식에 비해 길다.)
비상태 애플리케이션에서 토큰은 거의 모든 요청에 대해 전송되므로 데이터 트래픽 크기에 영향을 미칠 수 있다.
이미 발급된 토큰에 대해서는 돌이킬 수 없다. 세션/쿠키 방식은 악의적으로 활용될 경우, 그냥 해당 세션을 지우면 되지만, JWT는 유효기간이 다 될 때까지 사용할 수 있다. => Access Token 유효 기간을 짧게 설정하고 Refresh Token 이라는 새로운 토큰을 발급하면서 해결 가능. -> OAuth와 연관.
Payload의 정보가 제한적이다. 앞서 서두에서 말한 self-contained와 연관되어 있다. Payload는 따로 암호화되지 않으므로 디코딩이 자유롭고, 디코딩할 경우 누구나 정보 확인 가능하기 때문에 Payload에는 중요한 정보를 넣을 수 없다. 이는 유저의 정보가 전부 서버 저장소에 안전하게 보관되는 세션/쿠키 방식과 비교했을 때 큰 단점이다. 그래서

참고
https://mangkyu.tistory.com/56
https://thgus13.tistory.com/4
https://dextto.tistory.com/233