만료 전인데도 API가 토큰을 거부한다면
만료 시각만으로 인증 성공 여부를 판단할 수는 없습니다. iss는 발급자, sub는 토큰이 나타내는 주체, aud는 의도한 수신 대상입니다. 다른 API용 토큰을 보내고 있지 않은지 확인하세요. aud는 문자열이나 문자열 배열일 수 있습니다.
이 값은 모두 토큰에 적힌 주장입니다. 디코더는 내용을 보여 줄 뿐 발급자가 진짜인지 증명하지 않습니다. 필수 클레임과 권한 규칙은 애플리케이션에서 정해야 합니다.
JWT의 세 부분 읽기
일반적인 서명 JWT는header.payload.signature로 구성됩니다. 헤더와 페이로드는 UTF-8 JSON을 Base64url로 인코딩한 값입니다. 마지막 부분은 서명 또는 MAC 바이트이므로 JSON으로 읽는 대상이 아닙니다.
토큰만 넣거나Bearer, Authorization: Bearer 접두사를 붙여도 됩니다. HTTP 요청 전체를 붙여넣지는 마세요. 결과 JSON은 각각 복사할 수 있고, 큰 정수와 지수 표기를 포함한 원래 숫자 표현이 유지됩니다.
exp와 JavaScript 타임스탬프의 단위 차이
exp는 만료 시각, nbf는 사용을 시작할 수 있는 시각, iat는 발급 시각입니다. NumericDate는 Unix epoch 이후의 초 단위 값입니다. 1704067200은 2024년 1월 1일 00:00 UTC이며 밀리초 값이 아닙니다.
비교에는 기기 시각을 쓰고 시계 오차에 대한 여유 시간을 적용하지 않습니다. 미래의 iat는 점검할 단서이지만 이 도구가 자동으로 토큰 전체를 무효 처리하지는 않습니다. 실제 허용 여부는 서버의 검증 정책을 따라야 합니다.
디코딩은 복호화나 서명 검증이 아닙니다
Base64url은 암호화가 아니므로 일반적인 서명 JWT의 내용은 키 없이 읽을 수 있습니다. 검증하려면 신뢰할 키와 허용 알고리즘을 설정하고 서명, 발급자, 수신 대상, 시간 조건 등을 확인해야 합니다. 토큰이 주장하는 alg만으로 신뢰 설정을 선택해서는 안 됩니다.
키 URL에 접속하거나 내장 키를 사용하지 않습니다. 다섯 부분의 암호화 JWE, 중첩 JWT, b64: false는 지원하지 않습니다. 입력은 50,000자와 JSON 중첩 64단계로 제한하며 중복 키는 오류로 처리합니다.
예제로 살펴보기
자주 묻는 질문
디코딩에 secret이 필요한가요?
헤더와 페이로드를 읽는 데는 필요하지 않습니다. 공유 비밀 키나 공개 키는 서명 검증에 사용되며, 이 도구는 서명 검증과 JWE 복호화를 수행하지 않습니다.
alg: none은 어떤 뜻인가요?
암호학적 서명이 없는 토큰입니다. 세 번째 부분이 비어 있으므로 마지막 점은 남아 있어야 합니다. 내용이 표시된다는 이유만으로 인증에 사용할 수는 없습니다.
입력한 토큰이 서버에 저장되나요?
디코딩 API로 전송하거나 도구에서 저장하지 않으며 URL에도 넣지 않습니다. 실제 Bearer 토큰은 접근 권한을 가질 수 있으므로 기능을 살펴볼 때는 제공된 가상 예제를 사용하세요.
예제의 서명은 실제로 유효한가요?
아닙니다. 만료 예제의 exp는 2024년 1월 1일 01:00 UTC이고 서명은 임시 값입니다. Unicode 예제도 임시 서명을 사용하며 여러 언어와 aud 배열을 보여 줍니다. 서명 없는 예제는 alg: none입니다.
토큰 형식 오류는 어떻게 고치나요?
세 부분이 모두 있는지, 공백이나 따옴표, 패딩이 섞이지 않았는지 확인하세요. 헤더와 페이로드는 UTF-8 JSON 객체여야 합니다. 중복 키, 빈 서명과 alg의 불일치도 거부됩니다. 오류가 나면 이전 결과는 숨겨집니다.