OAuth 2.0, OIDC and PKCE
state, nonce and PKCE: why three protections?
Callback binding, token replay and code interception are different threats.
Understand the concept
State binds the authorisation response to the initiating client context. A high-entropy, session-bound, single-use value is a common approach. Check that the returned value matches the expected transaction, not merely that it exists. Encoding a redirect destination inside state still requires destination validation and integrity protection.
An OIDC nonce binds the request to the ID token. If sent, it must be checked in the returned token alongside signature, issuer, audience and lifetime validation. Matching a nonce alone does not make the token trustworthy. PKCE separately binds code redemption to the verifier.
Maintained libraries manage these protections according to their flow profiles. Do not remove protections based on an oversimplified slogan. Concurrent tabs need transaction-specific storage. On validation failure, reject the flow and restart safely rather than accepting a partially validated login.
When investigating callback security and multi-tab login problems.
Treating the three fields as synonyms and substituting one for another.
One topic. Three levels of depth.
state: response ↔ initiating transactionCallback transaction binding.
This page does not send requests to external servers. Messages are readable HTTP/1.1 illustrations, not HTTP/2 or HTTP/3 wire dumps. example.test is reserved for examples. Run commands and JavaScript only in your own test environment; never publish real tokens or cookies.
Try it yourself first.
The nonce matches but the ID token audience is wrong. Should it be accepted?
Show the solution and explanation
Reject: all required validations must succeed.No. One matching field does not override other validation requirements.