JWT 디코더
JSON Web Token(JWT)은 두 당사자 간 클레임을 표현하는 간결하고 URL 안전한 방식입니다. 대부분의 JWT는 무결성을 보장하지만 내용을 암호화하지는 않는 JWS(JSON Web Signature)를 사용하여 서명됩니다. 이 도구는 헤더와 페이로드를 디코딩하여 클레임을 표시하고, 타임스탬프를 읽기 쉬운 형식으로 보여주며, 토큰의 만료 상태를 표시합니다.
사양
주요 사용 사례
- OAuth 2.0 및 OpenID Connect 인증 흐름 디버깅
- ID 공급자(Auth0, Okta, Keycloak)의 액세스 토큰 및 ID 토큰 검사
- API 개발 중 토큰 클레임이 예상 값과 일치하는지 확인
- "401 Unauthorized" 오류 문제 해결 시 토큰 만료 확인
- 서드파티 서비스 통합 시 토큰 구조 이해
- 보안 검토를 위한 토큰 감사 (알고리즘, 클레임, 만료)
기능
- JWT 헤더와 페이로드 디코딩 (JWS 형식)
- 알고리즘(HS256, RS256, ES256, PS256, EdDSA) 및 토큰 유형 표시
- 등록된 클레임 파싱: iss (발급자), sub (주체), aud (대상), exp (만료), nbf (유효 시작), iat (발급 시각), jti (JWT ID)
- 읽기 쉬운 카운트다운과 함께 만료 상태 표시
- 디코딩된 섹션을 포맷된 JSON으로 복사
예제
OAuth 2.0 액세스 토큰
사용해 보기 →주체, 발급자, 만료를 포함한 표준 클레임이 있는 일반적인 액세스 토큰입니다.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE5MTYyMzkwMjJ9.4S5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5팁
- JWS 토큰(가장 일반적인 유형)은 서명되지만 암호화되지 않습니다. 토큰을 가진 누구나 Base64 디코딩으로 페이로드를 읽을 수 있습니다.
- JWE 토큰은 페이로드를 암호화하지만 덜 일반적입니다. 이 도구는 JWS 토큰을 디코딩합니다.
- 클레임을 신뢰하기 전에 항상 서버 측에서 서명을 검증하세요. 이 도구는 디코딩된 내용을 표시하지만 서명을 검증하지 않습니다.
- "alg": "none" 알고리즘은 보안 위험이며 서버에서 거부해야 합니다.
- 대칭 알고리즘(HS256)은 공유 비밀 키를 사용하고, 비대칭 알고리즘(RS256, ES256)은 공개/개인 키 쌍을 사용합니다.
- "exp" 클레임은 초 단위의 Unix 타임스탬프입니다. 만료된 토큰을 수락하지 않도록 확인하세요.
이해하기 JWT 디코더
JSON Web Token(JWT)은 현대 웹 인증 및 권한 부여를 위한 주요 토큰 형식입니다. JWT는 점으로 구분된 세 개의 Base64url 인코딩 세그먼트로 구성된 간결하고 URL 안전한 문자열입니다: 서명 알고리즘을 지정하는 헤더, 사용자 또는 세션에 대한 클레임을 포함하는 페이로드, 그리고 토큰이 변조되지 않았음을 보장하는 암호화 서명. 이 구조를 통해 누구나 간단한 Base64 디코딩으로 토큰 내용을 읽을 수 있지만, 서명 키를 가진 당사자만 유효한 토큰을 생성하거나 검증할 수 있습니다.
대부분의 JWT는 페이로드가 서명되지만 암호화되지 않는 JWS(JSON Web Signature) 형식을 사용합니다. 헤더의 "alg" 필드는 알고리즘을 지정합니다: HS256과 같은 대칭 알고리즘은 발급자와 검증자 모두에게 알려진 공유 비밀을 사용하고, RS256 및 ES256과 같은 비대칭 알고리즘은 서명에 개인 키를, 검증에 공개 키를 사용합니다. 비대칭 알고리즘은 서명 키를 손상시키지 않고 검증 키를 공개적으로 공유할 수 있으므로 분산 시스템에서 선호됩니다.
페이로드에는 RFC 7519에서 정의된 등록된 클레임이 포함됩니다: "iss"(발급자), "sub"(주체), "aud"(대상), "exp"(만료 시간), "nbf"(유효 시작), "iat"(발급 시각), "jti"(JWT ID). OAuth 2.0 및 OpenID Connect는 범위, 역할, 사용자 프로필 정보에 대한 추가 클레임을 계층화합니다. "exp" 클레임은 보안에 매우 중요합니다 - 만료가 없거나 지나치게 긴 수명을 가진 토큰은 일반적인 취약점입니다.
JWT는 OAuth 2.0 액세스 토큰, OpenID Connect ID 토큰, API 인증, 세션 관리에 사용됩니다. Auth0, Okta, Keycloak과 같은 ID 공급자는 애플리케이션이 공급자에 연락하지 않고도 검증할 수 있는 JWT를 발급하여 무상태 인증을 가능하게 합니다. 그러나 이는 취소가 어렵다는 것을 의미합니다 - 손상된 토큰은 만료될 때까지 유효하기 때문에 짧은 만료 시간과 토큰 갱신 흐름이 필수적인 보안 관행입니다.
JWS 토큰은 암호화가 아닌 Base64url로 인코딩되므로, 토큰을 소유한 누구나 헤더와 페이로드를 디코딩하여 읽을 수 있습니다. 비밀번호, 신용카드 번호, 비밀 정보와 같은 민감한 정보는 JWT 페이로드에 절대 포함해서는 안 됩니다. JWE(JSON Web Encryption) 토큰은 페이로드를 암호화하지만, 실제로는 훨씬 덜 일반적입니다. 인코딩과 암호화의 차이는 JWT를 다룰 때 이해해야 할 가장 중요한 사항 중 하나입니다.
서명 알고리즘의 선택은 중요한 보안 영향을 미칩니다. HS256은 서명과 검증 모두에 단일 공유 비밀을 사용하는 대칭 알고리즘으로, 구현이 간단하지만 양쪽 모두 동일한 비밀을 안전하게 저장해야 합니다. RS256과 ES256은 서명에 개인 키를, 검증에 공개 키를 사용하는 비대칭 알고리즘입니다. 분산 시스템에서는 공개 키를 JWKS(JSON Web Key Set) 엔드포인트를 통해 공개적으로 공유할 수 있어 서명 키를 손상시키지 않으므로 비대칭 알고리즘이 선호됩니다. "alg": "none" 옵션은 서명이 전혀 없는 미서명 토큰을 나타내며, 누구나 임의의 클레임으로 토큰을 위조할 수 있습니다. 잘 알려진 공격은 알고리즘 헤더를 "none"으로 변경하고 서명을 제거하는 것입니다. 서버는 항상 허용 목록에 대해 알고리즘을 검증하고 미서명 토큰을 거부해야 합니다.
적절한 만료 처리는 JWT 보안에 필수적입니다. 애플리케이션은 토큰을 신뢰하기 전에 모든 요청에서 "exp" 클레임을 확인해야 합니다. 토큰이 만료되면, 안전하게 저장된 리프레시 토큰(종종 httpOnly 쿠키에 저장)을 사용하여 사용자가 다시 로그인할 필요 없이 새 액세스 토큰을 얻을 수 있습니다. 액세스 토큰 수명을 짧게 유지하는 것(일반적으로 5~15분)은 토큰이 손상된 경우 노출 기간을 제한합니다. 액세스 토큰이 실제로 만료되기 전에 사전에 토큰 갱신을 구현하면 애플리케이션에서 사용자에게 보이는 중단을 방지합니다.