JWT를 안전하게 디코딩하기

문제 상황

JWT는 짧고 로그에 붙여넣기 쉽지만, 디코딩된 payload에는 사용자 식별자, scope, tenant ID, 세션 데이터, 만료 시간이 들어 있을 수 있습니다. 디코딩은 인증 문제를 디버깅하는 데 도움이 되지만 signature 검증이나 토큰을 신뢰해도 된다는 증명은 아닙니다.

이럴 때 사용하세요

• API가 401 또는 403을 반환해 토큰 만료, audience, scope를 먼저 확인해야 할 때 사용합니다.
• 로그인 후 역할이나 권한이 빠진 것처럼 보일 때 적합합니다.
• 지원 사례에 일부 가려진 토큰이 포함되어 있고 비밀이 아닌 claim만 확인해야 할 때 도움이 됩니다.
• staging 토큰은 동작하지만 production API에서 실패해 issuer, audience, tenant claim을 비교해야 할 때 사용합니다.
• 요청이 access token, ID token, refresh 관련 값을 잘못된 위치에 사용했는지 확인해야 할 때 사용합니다.

단계

1. 1단계

   민감한 값 먼저 가리기

   티켓, 스크린샷, 채팅, 문서에 공유하기 전에 실제 token 값과 사용자 식별자를 제거하거나 대체합니다.

2. 2단계

   토큰 종류와 환경 확인

   토큰이 development, staging, production 중 어디에서 왔는지, API, 브라우저 세션, identity claim, refresh flow 중 어디에 쓰이는지 확인합니다.

3. 3단계

   header와 payload 디코딩

   토큰을 로컬에서 열어 algorithm, key identifier, issuer, audience, subject, expiry, scope claim을 확인합니다.

4. 4단계

   시간 기반 claim 확인

   exp, nbf, iat 값을 실패한 요청에 관여한 클라이언트나 서버의 시각과 비교합니다.

5. 5단계

   신뢰하기 전 별도 검증

   토큰을 진짜로 신뢰하기 전에는 애플리케이션, identity provider, backend library에서 signature를 검증해야 합니다.

6. 6단계

   실패한 요청과 claim 연결

   디코딩한 audience, issuer, scope, role, tenant 식별자를 요청이 거부된 API route, 환경, 권한 검사와 비교합니다.

예시

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzQyIiwic2NvcGUiOiJyZWFkOmJpbGxpbmciLCJhdWQiOiJhcGkiLCJleHAiOjE3MDAwMDAwMDB9.signature

{
  "sub": "user_42",
  "scope": "read:billing",
  "aud": "api",
  "exp": 1700000000
}

흔한 실수

자주 묻는 질문