일반적인 액세스 토큰
- 입력
- eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJKYW5lIiwiaWF0IjoxNzAwMDAwMDAwLCJleHAiOjE3MDAwMDM2MDB9.signature
- 결과
- sub: 12345 · exp: 2023-11-14 23:13 UTC
헤더, 페이로드, 서명이 점으로 구분됩니다.
JWT 디코더
JWT를 붙여넣으면 헤더와 클레임을 보여줍니다. 만료·발급 시각을 읽기 쉬운 날짜로 변환하고 표준 클레임의 의미를 함께 설명합니다. 토큰은 브라우저 밖으로 나가지 않습니다.
전부 브라우저 안에서 처리됩니다. 이 페이지는 정적 파일입니다. 입력한 내용은 탭 안에만 머물고 서버로 전송되지 않으며 창을 닫으면 사라집니다. 실제 토큰이나 설정을 붙여넣어도 안전합니다.
이럴 때 씁니다
- 401이 떨어지는데 토큰이 만료된 건지 audience가 틀린 건지 가려내야 할 때.
- API를 탓하기 전에 액세스 토큰이 실제로 어떤 scope나 role을 담고 있는지 확인할 때.
- OIDC 연동을 디버깅하면서 발급자와 키 ID를 확인할 때.
실제 예제
만료 시각 읽기
- 입력
- "exp": 1700003600
- 결과
- 2023-11-14 23:13 UTC
exp는 밀리초가 아니라 초 단위입니다. 밀리초를 넣으면 55000년이 나오는데 실제로 자주 나오는 버그입니다.
위험한 헤더
- 입력
- {"alg":"none"}
- 결과
- 서명 없는 토큰
alg: none 을 그대로 받아들이는 라이브러리는 위조 토큰을 통과시킵니다. 서버에서 기대하는 알고리즘을 고정하세요.
자주 틀리는 부분
페이로드가 비공개라고 생각하는 것
JWT는 서명된 것이지 암호화된 것이 아닙니다. 토큰을 가진 사람은 이 페이지가 하듯 모든 클레임을 읽을 수 있습니다. 민감한 정보를 넣지 마세요.
디코더의 유효 표시를 믿는 것
디코딩은 진위를 증명하지 않습니다. 완벽하게 읽히면서 완전히 위조된 토큰도 있습니다. 판단은 서버의 서명 검증만이 내릴 수 있습니다.
만료 문제를 시계 오차와 혼동하는 것
토큰이 발급되자마자 만료된다면 iat 클레임과 서버 시계를 비교해 보세요. 장비 간 몇 분의 시계 차이만으로도 정상 토큰이 거부됩니다.
자주 묻는 질문
제 토큰이 어딘가로 전송되나요?
아니요. 이 페이지는 정적 파일이고 디코딩은 브라우저에서 Base64와 JSON 파싱으로 처리됩니다. 기록되거나 전송되는 것이 없으며 네트워크 탭에서 직접 확인할 수 있습니다.
왜 서명이 유효한지는 알려주지 않나요?
검증하려면 서명 시크릿이나 발급자의 공개 키가 필요합니다. 운영 서명 키를 웹 페이지에 붙여넣는 습관은 그렇게 얻는 편리함보다 훨씬 큰 위험입니다.
exp 와 nbf 는 어떻게 다른가요?
exp 는 토큰이 더 이상 받아들여지지 않는 시점이고, nbf 는 받아들여지기 시작하는 시점입니다. 미리 발급된 토큰은 nbf 가 미래일 수 있고 그때까지는 거부됩니다.