JWT를 디코딩하고 해당 클레임을 안전하게 검사하는 방법
빠른 답변
JWT은 점으로 연결된 3개의 Base64URL 문자열(header.payload.signature)입니다. 주장을 검사하기 위해 Base64URL 디코딩으로 헤더와 페이로드를 디코딩합니다. 그러나 디코딩은 데이터를 읽기만 할 뿐 진위 여부는 확인하지 않습니다. 모든 주장을 신뢰하기 전에 항상 서버의 서명을 확인하십시오. JWT 디코더를 사용하여 브라우저에서 토큰을 검사하세요.
소개
JSON 웹 토큰(JWT, RFC 7519)은 인증 및 권한 부여에 사용되는 URL 안전 토큰 형식입니다. 여기에는 점으로 구분된 3개의 Base64URL 인코딩 부분(header.payload.signature)이 있습니다. 헤더는 알고리즘을 설명하고, 페이로드는 클레임(사용자 ID, 역할, 만료)을 전달하며, 서명은 토큰이 신뢰할 수 있는 당사자에 의해 발행되었음을 증명합니다. 결정적으로 헤더와 페이로드는 암호화되지 않고 인코딩되어 누구나 읽을 수 있습니다.
단계별
-
토큰을 세 부분으로 나누기
JWT은 xxxxx.yyyyy.zzzzz와 같습니다. 점 문자를 분할하여 헤더(파트 0), 페이로드(파트 1) 및 서명(파트 2)을 가져옵니다. 정확히 세 부분이 없으면 토큰의 형식이 잘못된 것입니다.
-
Base64URL로 헤더를 디코딩합니다.
헤더는 {"alg":"HS256","typ":"JWT"}와 같은 Base64URL 인코딩 JSON 개체입니다. Base64URL은 + 및 / 대신 - 및 _를 사용하고 패딩을 생략합니다. 디코딩한 다음 JSON.parse를 사용하여 알고리즘과 유형을 읽습니다. 우리의 JWT 디코더는 이 작업을 자동으로 수행합니다.
-
페이로드(클레임)를 Base64URL로 디코딩합니다.
페이로드는 클레임의 JSON 개체입니다. 등록된 클레임에는 iss(발급자), sub(주제), aud(대상), exp(만료), nbf(이전 아님), iat(발행자) 및 jti(토큰 ID)가 포함됩니다. 비공개 청구는 애플리케이션별로 다릅니다(예: 역할, 이메일). 디코딩하고 검사하지만 확인될 때까지 신뢰하지 마십시오.
-
만료 및 이전 청구를 확인하십시오.
exp 및 nbf는 Unix 타임스탬프(초)입니다. 현재 시간이 exp를 지난 경우 토큰은 만료되므로 거부해야 합니다. 현재 시간이 nbf 이전이면 토큰이 아직 유효하지 않은 것입니다. UX에 대해서는 클라이언트 측에서 확인하고 보안을 위해 서버 측에서는 적용하십시오.
-
서버에서 서명을 확인하세요(클라이언트 측 아님).
서명은 HS256의 경우 HMAC-SHA256(secret, header.payload), RS256/ES256의 경우 RSA/ECDSA 서명입니다. 확인에는 브라우저에 절대 도달해서는 안되는 비밀 또는 공개 키가 필요합니다. jsonwebtoken(노드) 또는 jose와 같은 라이브러리를 사용하여 확인하세요. 절대 직접 암호화폐를 작성하지 마세요.
예
일반적인 JWT(3개 부분)
입력: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpmeJf36POk6yJV_adQssw5c
산출: Header: {"alg":"HS256","typ":"JWT"} Payload: {"sub":"1234567890","name":"John Doe","iat":1516239022}
표준 클레임으로 디코딩된 페이로드
입력: 실제 인증 토큰의 페이로드
산출: {"sub":"user-42","iss":"freeonlinetoolsgo.com","exp":1767229200,"iat":1767225600,"role":"admin"}
만료된 토큰 감지
입력: exp: 1609459200 (2021-01-01) 2026-08-28에 확인됨
산출: Token is expired —current time (1767225600) > exp (1609459200). Reject and prompt re-login.
일반적인 문제
- 디코드를 검증으로 처리: 누구든지 클레임과 가짜 서명을 사용하여 JWT을 만들 수 있습니다. 디코딩은 페이로드를 읽지만 아무것도 증명하지 못합니다. 클레임을 신뢰하기 전에 항상 서버의 비밀/공개 키로 서명을 확인하세요.
- 'none' 알고리즘 사용: JWT 사양은 보안되지 않은 토큰에 대해 alg: none을 허용합니다. 검증자가 alg: none을 수락하면 공격자가 토큰을 위조할 수 있습니다. 아무것도 거부하지 않고 예상되는 알고리즘을 화이트리스트에 추가하도록 라이브러리를 구성하세요.
- localStorage에 JWT 저장: XSS는 localStorage를 읽고 토큰을 추출할 수 있습니다. 세션 토큰의 경우 httpOnly, Secure, SameSite=Strict 쿠키를 선호하거나 새로 고침 토큰 쿠키가 있는 단기 메모리 내 토큰을 선호하세요.
- exp/aud/iss를 확인하지 않음: 도난당한 토큰은 만료될 때까지 유효합니다. 서비스 간 토큰 재생을 방지하려면 모든 요청에서 항상 exp(만료), aud(의도 대상) 및 iss(발급자)를 확인하세요.
팁
- 단기 액세스 토큰(15분)과 장기 새로 고침 토큰을 사용합니다. 이렇게 하면 액세스 토큰이 도난당할 경우 기간이 제한됩니다.
- 여러 서비스가 토큰을 확인할 때 HS256(대칭)보다 RS256(비대칭)을 선호합니다. 각 서비스는 공개 키를 가져오고 발급자만 개인 키를 갖습니다.
- 개발 중에 당사의 JWT 디코더를 사용하여 서버가 발행하는 내용을 검사하십시오. 토큰을 어디에도 보내지 않고도 디코딩된 헤더, 페이로드 및 사람이 읽을 수 있는 청구 요약을 표시합니다.
- 민감한 데이터(비밀번호, PII)를 JWT 페이로드에 넣지 마십시오. 이는 암호화되지 않고 Base64으로 인코딩되며 토큰을 가로채는 사람은 누구나 모든 청구를 읽을 수 있습니다.