01
초 단위를 확인
exp, nbf, iat의 NumericDate는 Unix 초입니다. 밀리초 값을 그대로 넣으면 다른 시각이 됩니다.
개발자 참고 자료
JWT 클레임과 OAuth 오류
클레임 이름이나 OAuth 오류 코드를 검색해 응답 위치, 가상 예시, RFC 출처를 확인하세요.
JWT 클레임
검색 결과
exp
응답 위치: JWT 클레임 · RFC 7519
의미: 만료 시각이며 NumericDate는 Unix 초 단위입니다.
밀리초가 아닌 Unix 초로 비교하세요.
가상 응답 예시
{ "exp": 1893456000 }가상 데이터이며 실제 인증 정보로 사용하면 안 됩니다.
검색은 브라우저 안에서만 이루어지며 출처를 눌렀을 때만 이동합니다.
분류
1개 표시 / 전체 23개
RFC 7519 / 6749 / 6750확인: 2026년 9월 23일
JWT 클레임에서 exp나 aud를 읽는 일과 토큰의 서명을 검증하는 일은 다릅니다. 이 참조 자료는 비밀 값을 붙여 넣지 않고 등록된 필드의 의미를 찾도록 돕습니다.
같은 OAuth 오류도 인가 리디렉션, 토큰 JSON, Bearer 응답 헤더 중 어디에서 나왔는지에 따라 해석이 달라집니다. 제공자 문서의 액세스 토큰 클레임은 이 기본 목록보다 더 많을 수 있습니다.
JWT 클레임 참조가 필요한 이유
JWT 클레임 참조가 필요한 이유
값과 검증을 구분
JWT 클레임 exp에는 Unix 초 단위의 가상 값과 RFC 링크가 붙습니다. payload를 읽었다고 서명이나 세션이 확인되는 것은 아닙니다.
오류 위치를 함께 확인
invalid_request는 리디렉션 쿼리, JSON 본문 또는 Bearer 헤더에 나타납니다. 응답 위치를 분리해 문제 지점을 찾습니다.
필드에서 원문까지
02
오류가 나온 위치 확인
OAuth 오류 코드를 보기 전에 인가, 토큰, 리소스 서버 중 어느 응답인지 구분하세요.
03
고정된 RFC 절 확인
출처 링크와 제공자 문서를 대조하고 실제 토큰은 별도의 디버거에서 살펴보세요.
필드와 오류를 한자리에서
일곱 개 등록 클레임
RFC 7519의 JWT 클레임 일곱 개에 가상 예시와 각 정의의 링크를 제공합니다.
엔드포인트별 오류
RFC 6749 인가 오류와 토큰 오류를 분리해 같은 error 값의 맥락을 보존합니다.
Bearer 인증 헤더
RFC 6750 오류에 WWW-Authenticate 예시와 권장 HTTP 상태를 붙였습니다.
참조 범위와 제한
- 인증 여부 판정 없음
- 이 JWT 클레임 페이지는 토큰을 받거나 서명을 검증하거나 현재 세션을 확인하지 않습니다.
- 확장 자동 수집 없음
- RFC 7519, 6749, 6750만 다룹니다. OIDC와 제공자 전용 오류는 자동으로 포함되지 않습니다.
- 설명 문구로 분기 금지
- error_description은 선택적인 사람용 설명입니다. error 값과 엔드포인트로 먼저 판단하세요.
- 인증 정보 입력 없음
- 실제 JWT, 서명 키, 인가 코드를 붙여 넣거나 URL 매개변수에 넣지 마세요. 고정 자료만 검색합니다.
- 서버 요청 없음
- 검색은 ID 제공자에게 요청하지 않고 관련 도구로 값을 자동 전달하지 않습니다. 실제 요청은 별도 도구에서 확인하세요.
- 오류 맥락 유지
- 같은 invalid_request도 응답 위치가 다르며 Bearer의 invalid_token과 insufficient_scope는 권장 상태가 다릅니다.
- 실시간 만료 표시 없음
- NumericDate 예시는 Unix 초를 사용합니다. 고정 값으로 현재 세션이나 입력하지 않은 토큰의 만료를 판단할 수 없습니다.
JWT 클레임 자주 묻는 질문
JWT에서 iss와 aud는 무엇을 뜻하나요?
iss는 발급자, aud는 의도된 수신자입니다. 실제 서비스에서 두 값을 검증해야 합니다.
모든 JWT에 exp 클레임이 필요한가요?
모든 JWT에 필수인 것은 아닙니다. RFC 등록과 애플리케이션의 필수 조건은 다릅니다.
invalid_grant와 invalid_client의 차이는 무엇인가요?
invalid_client는 클라이언트 인증 실패, invalid_grant는 grant나 갱신 토큰 문제입니다.
error_description으로 오류를 분기해도 되나요?
권장하지 않습니다. 선택적인 사람용 설명이라 제공자별 문구가 바뀔 수 있습니다.
JWT를 디코딩하면 유효성도 확인되나요?
아니요. 디코딩 뒤에도 서명, 발급자, 수신자, 시간, 서비스 정책 검증이 필요합니다.
누락되거나 잘못된 항목을 발견했나요?