OpenID Provider responsibilities
All domains, identifiers, and tokens in these examples are fictional.
The printer compares the ID token's aud with photo-printer, its nonce with demo-nonce-3, and its signature with a key from the photo service's key set. Each comparison assumes the photo service put the right value there. If the photo service copied the wrong nonce into tokens, or gave your subject identifier to someone else, the printer's checks would still pass, and the printer would sign in the wrong person.
Those values are the responsibility of the team on the other side, the one that runs the photo service's OpenID Provider. Much of that team's work is shared with any authorization server. The checks it makes on every request, such as exact redirect URI matching, PKCE, and client authentication, are the ones Redirects and authorization codes, Proof Key for Code Exchange (PKCE), and Client authentication methods explained. Authorization server responsibilities, in the OAuth lessons on implementation and operations, covers running the service around those checks: the client registry, recorded approvals, issuing and storing codes, tokens, and signing keys, metadata, revocation, and token lifetimes. OpenID Connect adds promises about who you are and how you signed in.
What relying parties count on
Almost every check a relying party makes has a matching duty at the provider:
| The printer checks | The photo service must |
|---|---|
iss is exactly https://auth.photos.example | Use one exact issuer string in its discovery document and in every token, with no variation in case, path, or trailing slash. |
The signature, with a key from jwks_uri | Publish each key before signing with it, protect the private keys, and keep a retired key published until nothing it signed is still valid. |
aud contains photo-printer | Address each ID token to the client the sign-in was for. |
nonce is demo-nonce-3 | Copy the nonce from the request exactly, whenever the request had one. |
auth_time and acr | Report when you actually authenticated and what was actually achieved. |
iss and sub identify your printer account | Never change a subject or give it to anyone else. |
UserInfo returns the same sub | Return the same subject for the same person and client from every endpoint. |
The issuer is the root of all of it. Relying parties store it with every account link, so changing it, even by adding a trailing slash, makes every existing customer look new. A provider that moves to new infrastructure keeps the issuer string, and one that hosts several organizations can give each its own stable issuer.
Signing keys follow the publisher's side of Storing and using keys. The photo service signs ID tokens with RS256, the default algorithm for ID tokens and one every provider's metadata must list, under the key photos-rs-2026-09. Before it signs anything with photos-rs-2027-01, it publishes the new key long enough for relying parties' cached key sets to include it. Afterward it keeps the old key published until no unexpired token signed with it remains. The private keys never leave the hardware or service that signs with them, and the team has rehearsed withdrawing a leaked key.
Authenticating and releasing claims
A relying party can ask for a fresh sign-in or a particular kind of authentication, but only the provider can deliver it. OpenID Connect lists features every provider must implement, and most concern this part of its work: honoring prompt=none and prompt=login, enforcing max_age, returning auth_time when it is requested, and accepting acr_values, display, and ui_locales without error.
Supporting a parameter means doing what it says. With prompt=none, the photo service shows no page at all. It completes the sign-in silently or answers with login_required or another of the errors from Authentication errors. With max_age=300, it compares the time of your last authentication with the current time, asks you to sign in again if more than five minutes have passed, and puts the new auth_time in the ID token. A provider that ignored max_age but reported the real auth_time would at least let a careful relying party notice. One that wrote the current time into auth_time without asking you anything would defeat the check completely.
The same honesty applies to acr and amr. They describe what happened, not what was requested. If you signed in with a password alone, the token does not claim a context that needs a second factor because the relying party asked for one. When the provider cannot meet a requirement, it reports the context it did achieve, or fails the request when the relying party marked the requirement as essential, and the relying party decides what to do next.
Releasing claims is the other half. The photo service releases what the scopes and any claims request asked for, only to the client that asked, and only with your agreement where its policy requires it. Its consent screen names the printer and says plainly what will be shared. It remembers your decision, and lets you review and withdraw it later. It sets email_verified to true only when it verified that address itself, under rules it can describe to relying parties. None of this can be checked from the relying party's side, which is why choosing whom to trust matters.
One detail of the response is easy to miss. After you submit your password on the photo service's sign-in form, the provider sends your browser to the printer's callback with a 302 redirect or, better, a 303. A 307 would tell your browser to repeat the POST, form fields included, to the callback, which would hand your photo service password to the relying party.
Keeping subjects stable
Your printer account is linked to user-2048 at https://auth.photos.example. The printer stored that pair because the specification promises that a subject is unique within its issuer and never reassigned. The events that threaten that promise are mostly routine:
- Changing an email address or username. The subject must not be derived from either. Otherwise you would become a stranger to the printer on the day you changed your email address.
- Closing an account. A closed account's subject is retired, not given to the next new account. Otherwise the next person to sign up could inherit your printer orders and saved addresses.
- Migrating systems. Moving accounts to a new user store, or merging another service's accounts into this one, carries existing subjects across unchanged, along with the issuer.
- Pairwise identifiers. A provider that gives each relying party a different subject must calculate it the same way every time for the same person and sector, including after a migration.
Subjects have a shape as well. Each is at most 255 ASCII characters and is compared exactly, case included, so user-2048 and User-2048 would be different accounts. A subject is not secret, and with public identifiers every relying party you use receives the same one, so it should not contain your email address, your name, or anything else about you.
Metadata, logout, and monitoring
The discovery document is a promise too. Relying parties read it to decide how to talk to the provider, so it lists only what the provider actually does: the response types, signing algorithms, claims, and endpoints it supports. A document that advertises backchannel_logout_supported before back-channel logout works leads relying parties into failures they cannot see. The jwks_uri it names stays reachable and fast, because relying parties fetch it at the moment someone is waiting to sign in.
Logout depends on the provider remembering where you signed in. When your photo service session ends, the relying parties registered for front-channel or back-channel logout can end their own sessions only if the provider notifies them, naming the person by sub, the session by the sid it put in their ID tokens, or both. Back-channel notifications travel from the provider's servers, so the photo service can record each delivery, notice a relying party that does not answer, and retry or report the failure.
Finally, the provider watches itself. The useful signals are mostly rates: sign-in failures for each client, codes presented twice, back-channel deliveries that fail, and requests for the key set that suddenly multiply because a relying party stopped caching it. A rise in codes presented twice might be an attack or one relying party's retry bug. Either way, the provider can help only if its logs record the client, the step, and the error, and never tokens, codes, or passwords.