nonce Claim in an OpenID Connect ID Token

The client generates a random value, sends it as the nonce parameter on the authentication request, and keeps a copy tied to that browser session. The authorization server copies the value into the ID token without changing it. The relying party then compares the claim against the stored copy and rejects the token if they differ or if the claim is missing when it expected one.

The attack this blocks is replay of a token captured somewhere else. Without a nonce, an ID token that is otherwise valid, correctly signed, in date, addressed to the right audience, can be injected into a different login attempt and accepted. Binding the token to a value only the initiating client knew makes that impossible, since the attacker's captured token carries the wrong nonce.

It is easy to confuse with the state parameter, which travels in the redirect and protects the request against cross site request forgery. state is checked before the token is even fetched and never appears inside the token. nonce lives inside the signed ID token and is checked after the signature. They defend different steps and are not substitutes for each other.

The decoder lists nonce under Custom claims with the raw string it found. It cannot verify anything about it, because the value it would need to compare against is in the client's own session, not in the token. What the tool is good for here is confirming that the authorization server actually echoed a nonce, which is the usual reason a login is failing with a nonce mismatch.