JWT(JSON Web Token), 누구신가요?🧐

JWT Image

들어가며

개인 프로젝트 진행 간 백엔드, 프론트 통신 단계에서 JWT라는 단어를 접하게되었다.
인증/인가, 세션과 토큰이라는 단어와 같이 나오는 단어였고, 대부분 큰플젝이 아니면 JWT쓴다고한다.
일단 찾아보고 공부하다보니 인증,인가 /세션, 토큰, 쿠키에 관한 이야기도 다른 글에서 추가로 적어 보도록하겠다.

너는 누구냐, JWT 🤯

JWT(Json Web Token)은 Json 객체에 인증이 필요한 정보들을 담은 후 비밀키로 서명한 토큰이다.
공식적으로 인증(Authentication) & 권한허가(Authorization) 방식으로 사용되는 인터넷 표준 인증 방식이다.
그리고, 필요한 모든 정보를 한 객체에 담아서 전달하기 때문에 JWT 한 가지로 인증을 마칠 수 있습니다.
( 보안 강화를 위해 예시로 JWE와 같은 방어 기술들을 함께 사용 가능합니다 )

JWT는 웹 표준(HTTP)을 따르기 때문에 대부분의 언어를 지원하기에 큰 장점으로 볼 수 있습니다.
가장 많이 사용되는 '로그인' 과정 위주로 풀어 보겠습니다.

JWT의 구조💻

JWT는 위와 같은 구조를 가지고 있습니다.
헤더, 내용, 서명이 '.'으로 구분하여 1개의 토큰을 이루고 완성된 토큰은 이와 같은 형태를 보입니다.

하단 토큰은 공식문서에서 예시이며, 인코더와 디코더를 볼 수 있으며
해당 링크를 통해 JWT 만들기 및 변하는 과정을 볼 수 있습니다.

Encoded

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Decoded

Header
Payload
Signature

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

헤더에서는 해시 알고리즘과 토큰의 타입을 정의 할 수 있습니다.

alg : Signature에서 사용하는 알고리즘
typ : 토큰 타입

HS256은 signature에서 HMAC SHA256을 의미하며, 해시 알고리즘 중 하나입니다.
타입의 값이 JWT은 이 토큰을 JWT로 명시해줍니다.

HS256에 대한 자세한 내용은 auth0 공식 문서를 통해 확인 가능합니다

Payload

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

내가 전달하고자하는 데이터를 포함할 수 있습니다.

데이터 각각의 Key를 claim이라고 부릅니다.

claim은 사용자가 원하는 Key, Value를 구성할 수 있으며,
registered, public, private 이렇게 3가지 종류가 있습니다.

registered claim:
필수는 아니지만 권장되는 미리 정의된 클레임 세트로 일부는 다음과 같습니다.
iss(발급자), exp(만료 시간), sub(주체), aud(대상) 등.
JWT는 압축되도록 되어 있으므로 클레임 이름은 3자 길이에 불과합니다.
public claim:
JWT를 사용하는 사람이 원하는 대로 정의할 수 있습니다.
그러나 충돌을 피하려면 IANA JSON 웹 토큰 레지스트리에서 정의하거나 충돌 방지 네임스페이스가 포함된 URI로 정의해야 합니다.
private claim:
이는 사용에 동의한 당사자 간에 정보를 공유하기 위해 생성된 사용자 지정 클레임이며 등록 클레임이나 공개 클레임이 아닙니다.

Payload는 Base64Url로 인코딩되어 JSON 웹 토큰의 두 번째 부분을 형성합니다.
서명된 토큰의 경우 이 정보는 변조로부터 보호되지만 누구나 읽을 수 있습니다.

⚡️ 암호화되지 않은 경우 JWT의 Payload 혹은 Header 요소에 비밀 정보는 넣으면 안된다.

Signature

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

서명 파트는 Base64 인코딩된 Header "." Payload 그리고 secret이 필요합니다.
secret은 유저가 지정하는 비밀 코드이며, 위와 같이 해싱하면 서명이 완성됩니다.

JWT의 장단점

📌 장점

Stateless (무상태):
• JWT는 서버에서 세션을 저장할 필요가 없기에, 애플리케이션이 무상태(Stateless)로 작동할 수 있습니다.
다양한 클레임 지원:
• JWT는 사용자 정보, 권한, 만료 시간 등의 정보를 클레임으로 저장 가능해 유연하게 사용 가능합니다.
Self-contained (자체 포함):
• JWT 자체에 필요한 정보(사용자 정보, 권한 등)가 포함되어 있어 추가적인 데이터베이스 조회가 필요 없는 경우도 있습니다.
확장성과 분산 시스템에 적합:
• Stateless 인증 방식이기 때문에 여러 서버가 JWT를 동일하게 검증 가능해, 분산 시스템에 유용합니다.
웹 표준 지원:
• JWT는 OIDC(OpenID Connect)와 OAuth 2.0 표준에서 인증 토큰으로 사용되며, 다양한 언어 및 프레임워크에서 지원됩니다.
네트워크 부하가 적다.
http헤더나 url 파라미터를 통해 간단하게 전송되기 때문에 네트워크 부하 현상을 적습니다.

📌 단점

보안 취약점:
• JWT는 정보(클레임)를 디코딩할 수 있어, 민감한 정보는 저장해서는 안 됩니다. 또한 토큰이 탈취되면 무단 사용이 가능합니다.
• 토큰은 Base64 URL로 인코딩되어 누구나 디코딩할 수 있지만, 서명(Signature)은 검증을 위한 것이지 암호화 아니다.
토큰 크기 문제:
• JWT는 사용자 정보와 서명을 포함해 일반적인 세션 ID보다 크기가 크기에 네트워크 트래픽이 증가할 수 있다.
갱신 및 만료 처리:
• JWT는 Stateless 특성상 서버에서 토큰 강제 만료 어려워 토큰이 유효한 동안은 사용이 가능하다.
• 이를 해결하기 위해 Refresh Token과 함께 사용하거나, 토큰 블랙리스트를 도입해야 할 수 있다.
무결성 검증 실패 시 문제:
• 토큰의 서명이 올바르지 않으면 전체 토큰이 무효화된다,토큰에 포함된 데이터에 의존하는 경우 애플리케이션에서 예외 처리가 필요하다.
무거운 페이로드 문제:
• 많은 클레임(Claim)을 담으면 페이로드가 커지고, 이는 성능 저하로 이어질 수 있기에 페이로드에는 최소한의 정보만 담는것을 권장한다.

정리

사용 목적 : JWT 토큰은 사용자 인증과 로그인 유지를 위해 쓰인다
토큰의 구조 : Header, Payload, Signature
Header: 서명 알고리즘 (공개키/개인키 or 비밀키)
Payload : 토큰 정보(대상, 발급시각, 만료시각)
Signature : (Header+Payload) 서명 (인증용)