JWT(Json Web Token) 구조 이해하기

JWT (JSON Web Token) 이란

JWT(JSON Web Token)이란 유저를 인증하고 식별하기 위한 JSON 토큰을 의미합니다.

이 토큰 내에는 사용자의 권한 정보와 같은 인증 정보가 Base64 URL 방식으로 인코딩되어 포함되어 있습니다.

 

클라이언트가 토큰을 HTTP 헤더에 실어 응답을 보내 서버가 클라이언트를 식별하고 인증/인가를 수행합니다.

---

JWT 구조

JWT는 세 파트로 나누어지며, 각 파트는 점으로 구분됩니다.

헤더(Header), 페이로드(Payload), 서명(Signature)으로 구성됩니다.

출처: https://research.securitum.com/jwt-json-web-token-security/

헤더(Header)

헤더에는 해시 암호화 알고리즘과 토큰 타입 정보가 있습니다.

• 알고리즘: 서명 생성에 사용할 알고리즘 종류
  • ex) HS256, RS256
• 타입: 토큰의 타입, 여기서는 JWT가 되죠.

페이로드(Payload)

페이로드에는 토큰에 담길, 서버와 클라이언트에서 주고받고자 하는 실제 정보들이 있습니다.

정보 하나를 '클레임(claim)'이라고 합니다.

• 클레임: key(name)-value 형식으로 이루어진 한 쌍의 정보 
• 클레임 예시
  • 표준 클레임(Registered Claim): JWT 사양에서 정의한 클레임 
    • iss(issuer: 발행자)
    • exp(expiration time: 만료 시간)
    • sub(subject: 제목)
    • iat(issue at: 발행 시간)
    • jti(JWT ID)
  • 공개 클레임(Public Claim): 사전에 정의된, 공개용 정보 전달을 위한 클레임
  • 비공개 클레임(Private Claim): 발급자와 수신자 간의 협의에 따라 정의된 클레임

 

서명(Signature)

서명은 헤더와 페이로드를 이어 붙인 후, 시크릿(Secret Key) 또는 프라이빗 키(Private Key)로 암호화한 값입니다.

암호화는 헤더에서 정의한 알고리즘 방식을 사용합니다.

 

이때 키(Key)는 서버에서만 갖고 있는 값으로 이 비밀키가 유출되지 않는 이상 타인이 복호화할 수 없습니다.

서명은 헤더와 페이로드의 무결성을 보장합니다. 클라이언트가 토큰을 위조하지 않았음을 서버가 서명을 검증하여 확인할 수 있게 해줍니다.

 

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

---

+ JWT 예시

JWT는 Base64URL로 인코딩이 되어 있습니다.

Base64URL은 웹(URL) 환경에서 안전하게 사용할 수 있도록 설계된 인코딩 방식으로

누구나 디코딩할 수 있어 암호화의 기능은 없습니다.

 

https://jwt.io/에서 JWT Decoder / Encoder 체험을 할 수 있습니다.

---

JWT 동작 방식

1. 사용자는 아이디/비밀번호 등의 인증 정보를 입력해 서버로 로그인 요청을 보냅니다.
2. 서버는 입력받은 정보를 확인하고, 인증이 성공하면  JWT를 생성합니다. 
   • 헤더와 페이로드를 정의하고, 시크릿 키와 페이로드를 헤더에 정의된 암호화 알고리즘으로 암호화하여 서명을 만듭니다.
3. 클라이언트는 서버로부터 받은 JWT를 저장합니다(로컬 스토리지 등). 이후 요청 시 HTTP 헤더 Authorization에 다음과 같이 JWT를 담아 보냅니다.
   • Authorization: Bearer <JWT>
4. 서버는 토큰의 유효성을 검증합니다.
   • 서명이 유효한지, 만료 시간이 지나지 않았는지
5. 서버는 페이로드에서 사용자 정보를 추출하여 인가 처리를 합니다.
6. 서버는 해당 요청을 처리하고, 결과를 응답으로 클라이언트에게 응답합니다.

---

JWT 장단점

✅ 장점

• 세션 저장소 불필요 (Stateless)
  • JWT 자체가 인증된 정보를 포함하므로, 세션 저장소 같은 별도의 저장소가 필요 없습니다.
  • 따라서 서버는 클라이언트의 상태를 기억하지 않는 무상태(stateless) 구조로 동작할 수 있습니다.
• 서버 확장에 유리
  • 무상태 아키텍처 덕분에, 서버 간 세션 공유가 필요 없어 확장에 적합합니다.
• 사용자 인증 정보가  인증 정보가 페이로드에 포함되어 있어, 요청 시마다 DB를 조회하지 않아도 됩니다.
• 비밀 키를 기반으로 서명을 생성하므로 데이터 위변조를 막을 수 있습니다.

---

💥 단점

• 토큰 자체에 사용자 정보가 있으므로, 토큰 탈취 시 위험할 수 있습니다.
• 토큰을 서버가 아닌 클라이언트에서 관리하기 때문 탈취당하면 대처하기 어렵습니다.
  • 이미 발급된 토큰을 중간에 강제로 무효화하기 힘듭니다.
• 페이로드에 많은 정보를 담아 토큰이 길어지면 네트워크 성능에 부담이 될 수 있습니다.
• 토큰 만료 시간 딜레마
  • 너무 짧으면 잦은 재발급으로 불편하고
  • 너무 길면 탈취 시 장기간 악용될 수 있어 적당히 균형잡아야 합니다.

---

 

참고자료

https://ivory-room.tistory.com/88

https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-JWTjson-web-token-%EB%9E%80-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC

https://research.securitum.com/jwt-json-web-token-security/

https://www.geeksforgeeks.org/json-web-token-jwt/