# OIDC Decoder > Paste an OpenID Connect ID token or a .well-known/openid-configuration document and decode it: the core claims, profile claims, endpoints, and capabilities, with checks for required claims, signing algorithm, nonce, and PKCE. - Tool: https://ronutz.com/en/tools/oidc - Family: Identity & tokens --- ## What it does Paste either an OpenID Connect ID token or a provider's `.well-known/openid-configuration` document, and the tool decodes it. For an ID token it reads the core identity claims, the standard profile claims, and the binding hashes, and runs a set of security checks. For a discovery document it lays out the provider's endpoints and capabilities. It detects which of the two you pasted automatically, and everything runs in your browser. ## OIDC in one paragraph OpenID Connect is an identity layer built on top of OAuth 2.0. OAuth answers "what is this app allowed to do"; OIDC adds "and who is the user". It does that by having the provider issue an **ID token**, a signed JWT that asserts who signed in, alongside the OAuth access token. Because an ID token is a JWT, the tool decodes it through the same JWT core used elsewhere on the site, then interprets it with OIDC's specific meaning. ## The ID token and its checks The core claims identify the token: `iss` (who issued it), `sub` (the stable user identifier), `aud` (the client it was issued for), and the timing claims. On top of these OIDC adds claims worth understanding: `nonce`, a value the client generates and the provider echoes back so a replayed token can be caught; `at_hash` and `c_hash`, which bind the ID token to the access token and the authorization code so they cannot be swapped; `amr`, the authentication methods used (values such as `pwd`, `otp`, or `mfa`, registered in RFC 8176); and standard profile claims like `name` and `email`. The tool's security checks look at exactly what a careful client would: that the required claims are present, that the signing algorithm is sound rather than `none` or weak, that a nonce is present, and that the audience is what you expect. ## The discovery document The `.well-known/openid-configuration` document is how a provider advertises itself. It lists the endpoints a client needs (authorization, token, userinfo, and the `jwks_uri` where the signing keys live), the scopes and response types it supports, the algorithms it will sign ID tokens with, and the PKCE code-challenge methods it accepts. Reading it tells you at a glance what a provider supports and whether it advertises modern protections such as `S256` PKCE. ## Using it Paste an ID token to decode its claims and see the security assessment, or paste a discovery document to read a provider's endpoints and capabilities. The decode is a pure read of what the token or document contains; it does not contact the provider. ## Standards and references - [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html) - ID token claims, the auth flows, nonce / aud / azp, at_hash / c_hash - [OpenID Connect Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html) - the .well-known/openid-configuration document fields and requirements - [RFC 6749 - The OAuth 2.0 Authorization Framework](https://www.rfc-editor.org/rfc/rfc6749) - the OAuth 2.0 layer OIDC builds on: scopes, grants, the token endpoint - [RFC 7519 - JSON Web Token (JWT)](https://www.rfc-editor.org/rfc/rfc7519) - the JWT container an ID token uses: registered claims, NumericDate - [RFC 8176 - Authentication Method Reference Values](https://www.rfc-editor.org/rfc/rfc8176) - the amr values (pwd, otp, mfa, hwk, ...) carried in an ID token - [RFC 7636 - Proof Key for Code Exchange (PKCE)](https://www.rfc-editor.org/rfc/rfc7636) - PKCE and the S256 code challenge method advertised in discovery ## Related reading - [OIDC Discovery: The openid-configuration Document](https://ronutz.com/en/learn/oidc-discovery.md): How the .well-known/openid-configuration document lets a relying party learn a provider's endpoints and capabilities automatically, what the issuer, jwks_uri, and signing-algorithm fields mean, why advertising the none algorithm is dangerous, and why PKCE S256 support matters. - [OIDC vs OAuth 2.0: Authentication vs Authorization](https://ronutz.com/en/learn/oidc-vs-oauth.md): Why OAuth 2.0 is about authorization and OpenID Connect is about authentication, the difference between an access token and an ID token, why using plain OAuth as a login mechanism is a known antipattern, and how to tell which token is which. - [OpenID Connect: An Identity Layer on OAuth 2.0](https://ronutz.com/en/learn/oidc-overview.md): What OpenID Connect adds to OAuth 2.0, the ID token at the center of it, the relying party and provider roles, how the authorization code flow delivers an ID token, and why an ID token is just a JWT you can decode and read. - [The ID Token Claims, and What a Relying Party Checks](https://ronutz.com/en/learn/id-token-claims.md): The claims inside an OIDC ID token: the required iss, sub, aud, exp, and iat; the nonce that stops replay; azp when there are multiple audiences; acr and amr for authentication strength; auth_time; and the at_hash and c_hash binding claims, with the validation a relying party performs on each. - [The OIDC Authorization Code Flow](https://ronutz.com/en/learn/oidc-authorization-code-flow.md): The authorization code flow is the recommended way an app gets an ID token: the user is redirected to the identity provider to log in, the app receives a short-lived code, and it exchanges that code at a back-channel token endpoint for the tokens. Keeping the token out of the browser is the whole point.