🥸 JWT(Json Web Token)

JWT는 유저를 인증하고 식별하기 위한 Token 기반 인증이다.
토큰 자체에 사용자의 기본 정보 또는 Auth가 포함된다.

JWT의 구조

JWT는 Header, Payload, Signature로 구성된다.
각 요소는 .으로 구분된다.

Header

JWT에서 사용할 Type(typ)과 해시 알고리즘(alg)의 종류가 담겨있다.

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

Payload

서버에서 전달해준 사용자의 정보 데이터(Claim)를 저장한다.
Claim은 Key:Value형태로 값을 가진다. 저장되는 정보에 따라 Registered Claims, Public Claims, Private Claims로 구분된다.

Registered Claims

iss : 토큰 발급자 (issuer)   
sub : 토큰 제목 (subject)   
aud : 토큰 대상자 (audience)   
exp : 토큰 만료 시간 (expiration)   
nbf : 토큰 활성 날짜 (not before), 이 날이 지나지 않으면 활성화되지 않는다.   
iat : 토큰 발급 시간 (issued at)   
jti : JWT 토큰 식별자 (JWT ID)

Public Claims

Public Claims는 충돌이 방지되어야한다.
주로 URI 형식으로 짓는다.

"https://munprooo.github.io/jwt/public":true

Private Claims

클라이언트와 서버 협의하에 사용되는 클레임이다. Public과는 달리 이름이 중복될 수 있으므로 충돌에 유의해야 한다.

Signature

Header와 Payload를 Base64로 인코딩 후, Header에 명시된 해시함수를 적용하고, 개인키로 서명한 전자서명이 담겨있다.
해당 값은 Header와 Payload가 변조되었는지 확인하기 위해 사용된다.

SigningKey를 서버에서 고정해서 사용하는 방법과 외부에서 동적으로 받아오는 방법이 있다.

서버에서 고정

• 코드로 고정

외부에서 동적으로 받아오기

• 환경 변수로 설정
• Config등 파일에서 읽어오기
• 외부 서비스 호출 (API 등)

👉 Conclusion

세션을 통한 사용자의 인증을 한다면, 서버에서 사용자의 로그인 기록을 저장하고 각 사용자의 요청마다 세션 ID를 통해 인증을 확인한다.
이 경우, 서버가 여러 대라면 로드 밸런싱을 했을 때 문제가 발생한다. 세션을 DB에 저장하면 문제를 해결하겠지만 리소스의 낭비가 생긴다.

JWT와 같은 토큰을 클라이언트에 저장하면 HTTP 헤더에 토큰을 첨부해서 요청하면 서버에선 토큰의 여부만 판별하면 된다.
서버가 여러 대 있더라도, 사용자가 본인의 인증,인가를 증명할 수 있어 관리가 편리해진다.

이 방식은 MSA에서 빛을 발한다.
각 서비스마다 자체적인 서버이므로 JWT방식을 쓰면 복잡한 세션관리가 필요 없이 토큰의 유효성만 검증하면 된다.