제 JWT가 서버로 전송되나요?+−
아니요. 디코딩은 브라우저의 atob 및 TextDecoder API만을 사용해 전적으로 브라우저 안에서 이루어집니다 - 토큰과 서명 검증을 위해 붙여넣은 비밀 키나 공개 키는 절대 기기를 벗어나지 않습니다.
이 도구가 서명을 검증할 수 있나요?+−
네, 최선 노력 기반의 보너스 기능으로 가능합니다. HMAC 비밀 키(HS256/384/512용)를 알고 있거나 PEM 형식의 공개 키(RS256/384/512 또는 ES256/384/512용)를 붙여넣으면, 도구가 브라우저의 Web Crypto API를 사용해 로컬에서 서명을 확인합니다. 키가 없으면 헤더와 페이로드만 디코딩되어 표시됩니다 - 디코딩 자체에는 서명 키가 전혀 필요하지 않습니다.
왜 알고리즘이 "none"으로 표시되나요?+−
"alg": "none"은 토큰이 전혀 서명되지 않았음을 의미합니다 - 누구든지 원하는 클레임을 써넣을 수 있었을 것입니다. 일부 라이브러리는 과거 이런 서명되지 않은 토큰을 유효한 것으로 잘못 받아들였고, 이는 잘 알려진 인증 우회 방법이 되었습니다. 이 도구는 놓치지 않도록 항상 눈에 띄게 표시합니다.
exp, iat, nbf는 무엇을 의미하나요?+−
RFC 7519의 표준 타임스탬프 클레임입니다: iat은 토큰이 발급된 시각, nbf는 토큰이 유효해지는 가장 이른 시점, exp는 더 이상 유효하지 않게 되는 시점을 나타냅니다. 세 값 모두 NumericDate(유닉스 epoch 이후 경과 초)로 저장되며, 이 도구는 이를 읽기 쉬운 날짜와 "2시간 후 만료"와 같은 상대 시간으로 변환합니다.
비밀 키 없이도 페이로드를 읽을 수 있는 이유는 무엇인가요?+−
JWT의 헤더와 페이로드는 암호화된 것이 아니라 base64url로 인코딩되었을 뿐이기 때문입니다 - 인코딩은 비밀 유지가 아닙니다. 토큰을 가진 사람은 누구나 이미 클레임을 읽을 수 있습니다. 서명은 키가 없는 사람이 클레임을 변조하지 않았음을 증명할 뿐입니다. 공격자가 직접 읽지 않기를 바라는 내용은 절대 JWT 페이로드에 넣지 마세요.
제 토큰에 3개의 부분이 있는데도 디코딩되지 않습니다 - 왜 그런가요?+−
세 세그먼트(헤더, 페이로드, 서명) 각각은 유효한 base64url 텍스트여야 하며, 헤더와 페이로드는 유효한 JSON으로 디코딩되어야 합니다. 이 도구는 헤더와 페이로드를 독립적으로 디코딩하고, 조용히 실패하는 대신 어느 쪽이 왜 잘못되었는지(잘못된 base64, 잘못된 UTF-8, 또는 유효하지 않은 JSON) 정확히 알려줍니다.