JWT 디코더

JWT는 RFC 7519(2015년 5월)에 정의되어 있으며, RFC는 영어 단어 "jot"처럼 발음하라고 권합니다. 흔히 쓰는 서명된 형태는 Base64url 문자열 세 개를 점으로 이은 header.payload.signature입니다. 헤더는 alg에 HS256이나 RS256 같은 서명 알고리즘을 적고, kid에 키 ID를 담는 경우가 많습니다. 페이로드는 클레임, 즉 JSON 필드를 담습니다. sub(사용자), iss(발급자), aud(대상 수신자), 그리고 1970년 1월 1일 UTC부터의 초 단위 시간인 exp, nbf, iat 등입니다. 디코더는 이 세 시간을 내 현지 시간과 ISO 8601로 바꾸고, 토큰이 만료되었는지, 아직 유효하지 않은지, 유효 기간 안에 있는지 알려 줍니다.

Base64url은 암호화가 아니라 인코딩이므로, 토큰을 가진 사람은 누구나 이 페이지처럼 페이로드를 읽을 수 있습니다. 클레임에 비밀번호, 카드 번호 같은 비밀 정보를 절대 넣지 마세요. 점으로 구분된 부분이 다섯 개인 토큰은 암호화된 토큰인 JWE이며, 키 없이는 내용을 읽을 수 없고 디코더도 그렇게 알려 줍니다. Authorization 헤더에서 함께 복사된 앞부분의 "Bearer "는 자동으로 제거됩니다.

서명은 키를 가진 누군가가 헤더와 페이로드를 만들었고 그 뒤로 바뀌지 않았음을 증명합니다. 서명을 확인하려면 그 키가 필요합니다. HS256 같은 HMAC 알고리즘이면 공유 비밀 키, RS256, ES256, EdDSA면 발급자의 공개 키입니다. 운영 환경의 서명 비밀 키를 웹 페이지에 붙여 넣는 것은 나쁜 생각이고, 키 없이 토큰을 보증하는 척하는 디코더는 잘못된 안심만 줄 것입니다. 그래서 이 도구는 서명을 보여 주기만 하고 검증하지 않습니다. 여기서 보이는 내용은 사실이 아니라 토큰이 주장하는 내용으로 받아들이세요.

검증은 기대하는 알고리즘을 고정한 채 관리되는 라이브러리를 써서 서버에서 해야 합니다. 과거의 두 가지 실수가 그 이유를 보여 줍니다. 하나는 alg "none"을 받아들여 누구나 서명 없는 토큰을 위조할 수 있게 한 것이고, 다른 하나는 RS256을 기대하는 서버가 속아서 공개 키를 HMAC 비밀 키로 삼아 HS256 서명을 검사하게 되는 알고리즘 혼동입니다. 디코더는 디버깅용입니다. 제공자가 어떤 클레임을 발급하는지 보고, 잘못된 대상을 찾아내고, exp가 1분 전에 지나 세션이 실패했다는 사실을 확인하는 데 씁니다. Base64url 조각을 그대로 읽으려면 Base64 디코더를 이용하세요.