"401이 왜 나지"를 확인하는 가장 빠른 길
JWT는 점으로 나뉜 세 조각(헤더·페이로드·서명)이고, 앞의 두 조각은 그냥 Base64URL로 인코딩된 JSON입니다. 암호화가 아니라 인코딩이라 누구나 읽을 수 있습니다.
토큰을 붙여넣으면 만료 시각을 한국 시간으로 환산하고 남은 시간(또는 얼마나 지났는지)을 보여 줍니다. 인증이 갑자기 실패할 때 가장 먼저 확인할 것이 이것입니다.
표준 클레임
| 이름 | 뜻 |
|---|---|
exp | 만료 시각. 이 시각이 지나면 서버가 토큰을 거부합니다 |
iat | 발급 시각 |
nbf | 이 시각 전에는 유효하지 않음 |
iss | 발급자. 어느 인증 서버가 만들었는지 |
sub | 주체. 보통 사용자 ID |
aud | 대상. 이 토큰을 받아 줄 서비스 |
시각 클레임은 전부 초 단위 유닉스 타임스탬프입니다. 밀리초로 넣는 실수가 잦은데, 그러면 서버가 5만 년 뒤 만료로 읽습니다.
서명은 검증하지 않습니다
이 도구는 토큰을 읽기만 합니다. 서명이 올바른지는 확인하지 않습니다. 검증하려면 비밀키(HS256) 또는 공개키(RS256)가 필요한데, 비밀키를 웹페이지에 붙여넣게 만드는 건 그 자체로 위험한 설계라 넣지 않았습니다.
다시 말해 디코딩에 성공했다는 것이 그 토큰이 유효하다는 뜻은 아닙니다. 누구든 페이로드를 고쳐 다시 인코딩할 수 있고, 그게 가짜라는 건 서명을 검증해야만 알 수 있습니다.
alg가 none이면
서명 없이 통과시키라는 뜻입니다. 옛 JWT 라이브러리들이 이걸 그대로 받아들여 인증이 통째로 뚫린 사건이 여러 번 있었습니다. 요약란에 경고를 붙여 둡니다 — 운영 토큰에서 이 값을 봤다면 곧바로 확인해야 합니다.
토큰이 서버로 전송되나요?
아닙니다. 액세스 토큰은 그 자체가 자격증명이라, 온라인 JWT 도구에 붙여넣는 것은 비밀번호를 붙여넣는 것과 다르지 않습니다. 이 페이지는 받아 온 뒤로는 네트워크를 쓰지 않습니다. 그래도 운영 환경의 살아 있는 토큰이라면, 확인한 뒤 폐기하는 습관을 들이는 게 좋습니다.
페이로드에 비밀번호를 넣어도 되나요?
안 됩니다. 페이로드는 누구나 읽을 수 있습니다. 서명은 내용을 감추는 것이 아니라 내용이 바뀌지 않았음을 보장하는 것입니다.
토큰 일부만 있는데 풀 수 있나요?
가운데 조각만 있다면 Base64 디코딩에 넣으면 페이로드 JSON이 나옵니다. base64url과 빠진 패딩을 자동으로 처리합니다.