JWT

JWT 구조

• Header : 토큰의 타입(typ)과 해싱 알고리즘(alg)으로 이루어져 있다.

{
	"typ": "JWT",
	"alg": "HS512" // HMAC SHA256, RSA
}

• Payload :
• JWT를 통해 실제 서버 간에 전송하고자 하는 데이터.
• 내용에는 Claim이 담겨 있고, JSON(Key/Value) 형태의 한 쌍으로 이루어져 있다.
• Payload는 암호화되지 않기 때문에 노출되어도 무방한 정보만 저장해야 한다. (ex) email, id 는 [X] → userId(일련번호) [O] 등..
• Reserved Claims, Public Claims, Custom Claims
• Reserved Claims : 정보 교환에 유용하도록 미리 정의 되어 있는 클레임 필수는 아니지만 권장사항!
JSON Web Token (JWT)
Registration requests should be sent to the mailing list described in [RFC7519].

https://www.iana.org/assignments/jwt/jwt.xhtml#claims
• iss : issuer - 토큰 발급
• exp : expiration time - 만료 시간
• sub : subject - 클레임 주제
• aud : audience - 토큰의 수신자
• iat : issued at - 토큰 발급 시간
• Public Claims 사용자 정의 클레임으로 충돌 방지를 위해 URI 포맷 사용
• Private Claims 클라이언트, 서버 간 합의해서 사용하는 클레임 공개 클레임과 다르게 Key/Value 구조를 사용하므로 충돌 가능성 유의!

• Signature :
• 토큰 생성 주체만 알고 있는 비밀키를 이용한 헤더에 정의된 알고리즘으로 서명된 값
• 비밀키(Secret)과 함께 인코딩 해놓음으로써, 악의적으로 Payload 정보를 바꿔도 signature를 통해 검증할 수 있다.
 

JWT 장단점

장점

• 사용자 인증에 필요한 모든 정보가 토큰 자체에 포함되어 있어 저장소가 필요 없음 수평확장이 쉽다. → Session Cluster 필요 없음

• Active User가 많은 서비스에 JWT 사용이 유리함 → Session 사용의 경우, Active User 수 만큼 Session을 저장해야 되기 때문에 스토리지 관리가 어려워짐

단점

• 토큰 자체가 항상 HTTP 요청에 포함되어야 하기 때문에 토큰이 커질수록 불리함 → 토큰 크기를 항상 작게 유지해야 한다.

• 유효기간이 남아 있는 정상적인 토큰에 대해 강제적 만료 처리가 어렵다. (ex) 사용자 로그아웃 시, 웹앱 등 모든 단말에서 로그아웃 처리가 불가능 → Session을 사용하는 경우에는 제어 및 만료 처리 등 보안상 이점이 있다.

ETC