Advanced OIDC Patterns

PKCE: the client generates a random code_verifier, hashes it to a code_challenge (S256), and sends the challenge with the authorisation request. After receiving the code, it sends the plain verifier. The server verifies the hash matches, so a stolen code is useless without the verifier.

Device flow: the device polls the token endpoint while displaying a user code and verification URL. The user visits the URL on their phone, authenticates, and approves. The next poll returns the access token. This avoids any redirect or browser requirement on the constrained device.

Token introspection: with opaque (random) access tokens, the resource server cannot validate by signature alone. It POSTs the token to /introspect. The AS responds with active: true/false plus claims. This centralises revocation — a revoked token is immediately reported as inactive on the next introspection call.

Dynamic registration: a client POSTs its metadata (redirect URIs, grant types, application name) to the registration endpoint and receives a client_id (and optionally a client_secret). Used by SaaS products that need to integrate with arbitrary OIDC providers without pre-registering with each one.

JARM: standard authorisation responses are plain query parameters vulnerable to manipulation in the browser history or by malicious extensions. JARM encodes the response as a JWT signed by the AS, which the client verifies. This enables non-repudiation and optionally encrypts the code and state from passive eavesdroppers.