OIDC ID Token Decoder
Decode an OpenID Connect ID token and pretty-print its claims.
Overview
The OIDC ID token decoder takes an OpenID Connect ID token and pretty-prints its header, payload, and signature. It surfaces standard claims (iss, aud, sub, nonce, exp, iat, auth_time, azp) plus any custom claims your identity provider added, with timestamps rendered in ISO-8601 alongside the raw epoch numbers.
It is built for identity engineers integrating with Auth0, Okta, Azure AD, Cognito, or Keycloak; QA engineers debugging "why is my user not authorised"; and security reviewers checking that audience and issuer values match what the spec requires. An OIDC ID token decoder beats hand-base64-decoding three segments every time you need to look at a token.
How it works
An OpenID Connect ID token is a signed JWT (RFC 7519) issued by an identity provider after a successful authentication flow. The OIDC Core 1.0 spec requires specific claims: iss (issuer URL), sub (subject — the stable user ID), aud (audience — your client ID), exp (expiry), iat (issued at), and nonce when a nonce was sent in the auth request. The token has three base64url segments joined with dots; the tool splits them, decodes the JSON, looks up algorithm and kid in the header, and resolves common Unix-time fields into human-readable timestamps. Signature verification is informational — the tool does not fetch JWKS — but the algorithm, key ID, and signature bytes are surfaced for cross-checking.
Examples
Token: eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJpc3MiOiJodHRwczovL2lzc3Vlci5leGFtcGxlIiwic3ViIjoiNDIiLCJhdWQiOiJjbGllbnQtaWQiLCJleHAiOjE3MTcwMDAwMDAsImlhdCI6MTcxNjk5NjQwMH0.<sig>
Header:
alg: RS256
kid: 1
Payload:
iss: https://issuer.example
sub: 42
aud: client-id
exp: 1717000000 (2024-05-29 18:13:20 UTC)
iat: 1716996400 (2024-05-29 17:13:20 UTC)
Token: ...with nonce, auth_time, email_verified claims
Output: full claim set + alignment notes (e.g. exp in the past = expired)
Token: malformed (only two segments)
Output: "Not a valid JWT — expected 3 dot-separated segments"
FAQ
Does this verify the token's signature?
No. Signature verification requires the issuer's JWKS, which means an outbound network call to /.well-known/openid-configuration. This tool decodes locally; pair it with a JWKS-fetching tool when you need real verification.
Why are some iss values URLs and others not?
OIDC requires iss to be a case-sensitive URL. If you see a non-URL value, the issuer is not OIDC-conformant — it might be a plain OAuth 2.0 JWT or a custom token.
What is azp?
The "authorized party" claim — present when the audience and the client requesting the token differ. Most flows leave it absent.
Should I trust claims without verification?
Never in code. For debugging, decoded claims are fine; for any authorisation decision, fetch the JWKS, verify the signature with the right key (matched by kid), and check iss, aud, and exp before trusting anything else.