Reading provider metadata
The printer's developer now has the photo service's configuration document open in full. Some of it repeats what the photo service already publishes for OAuth clients. The rest exists because the photo service is also an OpenID Provider, and those are the entries a relying party reads most closely.
All domains, identifiers, and keys in these examples are fictional. A few entries are left out, including the grant types and the endpoints for pushed requests and revocation that the photo service's OAuth metadata also lists:
{
"issuer": "https://auth.photos.example",
"authorization_endpoint": "https://auth.photos.example/authorize",
"token_endpoint": "https://auth.photos.example/token",
"userinfo_endpoint": "https://auth.photos.example/userinfo",
"jwks_uri": "https://auth.photos.example/jwks",
"end_session_endpoint": "https://auth.photos.example/logout",
"scopes_supported": ["openid", "profile", "email", "offline_access",
"photos.read", "albums.create", "photos.delete"],
"response_types_supported": ["code"],
"subject_types_supported": ["public", "pairwise"],
"id_token_signing_alg_values_supported": ["RS256", "ES256"],
"claims_supported": ["sub", "name", "given_name", "family_name", "email",
"email_verified", "picture", "locale", "updated_at"],
"claims_parameter_supported": true,
"code_challenge_methods_supported": ["S256"],
"authorization_response_iss_parameter_supported": true
}Endpoints and keys
Six entries are URLs. OpenID Connect Discovery requires some of them and leaves others to the provider:
| Entry | Status | What the printer uses it for |
|---|---|---|
issuer | Required | The exact name compared in this document and in every ID token. |
authorization_endpoint | Required | Where your browser goes with the authentication request. |
token_endpoint | Required, except at a provider that offers only the implicit flow | Where the printer exchanges the code for an ID token. |
jwks_uri | Required | The key set used to check ID token signatures. |
userinfo_endpoint | Recommended | Where the printer asks for profile claims, as The UserInfo endpoint will show. |
end_session_endpoint | Defined by RP-Initiated Logout, for providers that support it | Where the printer can send your browser to end your session at the photo service, as RP-initiated logout will show. |
The required list is longer than for OAuth authorization server metadata, where only the issuer and the response types are always required. Any relying party may need to check an ID token's signature, so OpenID Connect requires jwks_uri, and it adds two required capability lists of its own, for subject types and ID token signing algorithms.
Every address must use HTTPS, and the printer uses each one exactly as written. Nothing requires the endpoints to share the issuer's host, and some providers serve their key set or token endpoint from a different one, so the printer takes every address from the document rather than assembling it from the issuer.
The key set at jwks_uri holds more than the printer needs. It contains the RSA key photos-rs-2026-09, which signs ID tokens with RS256, and the EC key photos-2026-09, which signs the photo service's JWT access tokens with ES256. The printer picks the key named by an ID token's kid and uses it only with the algorithm it accepts for ID tokens, as Signing keys and rotation explained. The set contains public keys only. Discovery forbids private and symmetric keys in it.
Advertised capabilities
The entries ending in _supported describe what the provider can do. Read with sign-in in mind, they say:
scopes_supportednamesopenid, which every OpenID Provider must support. Here it also listsprofileandemail, which ask for groups of claims, andoffline_access, which asks for a refresh token. A provider may leave some scopes out of the list, so a missing scope is a question for its documentation rather than proof that the scope does not exist.response_types_supportedis required, and the photo service lists onlycode. Its ID tokens always come from the token endpoint. Values such asid_tokenorcode id_tokenwould mean ID tokens delivered through the browser, which belong to the older integrations described in Understanding implicit and hybrid integrations.subject_types_supportedis required. The photo service can give a client the samesubit gives every other client, or a different one for each. Public and pairwise subject identifiers compares the two.id_token_signing_alg_values_supportedis required and must include RS256, the default every relying party can count on. The photo service can also sign ID tokens with ES256 for clients that ask for it.claims_supportedlists claims the provider may be able to supply. It is not a promise to release any of them to a particular client, and it may not be complete.claims_parameter_supportedsays the provider accepts theclaimsrequest parameter, which Scopes and the claims parameter introduces.
The last two entries come from OAuth specifications that OpenID Providers use as well. code_challenge_methods_supported tells the printer that PKCE with S256 works here. authorization_response_iss_parameter_supported promises that every authorization response, including a sign-in callback, carries iss.
Missing entries have meanings of their own. A list with no values is left out rather than sent empty, a missing true-or-false entry such as claims_parameter_supported means false, and a few lists have defaults of their own. Missing grant types, for example, default to the authorization code and implicit grants, which is one reason the photo service's full document lists its grants rather than leaving them out.
None of these lists describe the printer. They describe what the photo service can do for clients that ask. ES256 appears among the ID token algorithms, but the printer's registration uses RS256, so an ID token for photo-printer signed with ES256 is rejected even though the provider supports it. Pairwise subjects appear too, but the printer's registration asks for public ones, so its sub for you is user-2048. The registration, not the metadata, decides which of the provider's options apply to a client, and Registering a relying party looks at those choices.
Using metadata safely
Metadata makes the printer's configuration shorter. It should not make the printer's rules weaker, and three habits keep it that way.
First, the document never widens what the printer accepts. Suppose a refreshed copy listed none or HS256 among the ID token algorithms. Nothing would change for the printer, whose allowlist comes from its registration. A library that chose the algorithm by reading the provider's list, or accepted anything on it, would let one line in a document undo a check from Validation and trust.
Second, a missing entry does not switch off a protection the printer relies on. If the photo service's document stopped listing code_challenge_methods_supported, the OAuth metadata rules would read that as no PKCE support. A relying party that responded by quietly dropping PKCE would sign people in with less protection from that moment on, because of one missing line. The printer keeps its own expectations instead. It goes on sending PKCE, as it would go on requiring iss if that promise vanished too, and it raises the change with its operators. Validating metadata and issuer identity, in Advanced OAuth, describes the same rule for OAuth clients.
Third, a refreshed copy is compared with the last one, not simply absorbed. Most refreshes change nothing. The photo service's key rotations happen inside the key set, at the same jwks_uri, rather than in this document. A copy that names a different issuer is not a change at all: it fails the checks in Provider discovery and is discarded. A few changes deserve a person's attention even when the document passes, such as a different jwks_uri or token endpoint, especially on a new host, or a security feature that disappears. Changes that make the printer stricter, such as a provider beginning to promise iss, are safe to adopt. Changes that would make it looser wait for someone to decide.