Metadata role
Metadata publishes identifiers, endpoints, capabilities, signing-key locations, and supported methods for an authorization server or protected resource. Discovery reduces manual configuration. It also turns identifier and URL handling into a trust decision.
Start from trust
Begin with an administrator-approved issuer, resource, or well-known location. Retrieve metadata over authenticated HTTPS. Verify that the returned issuer or resource identifier exactly matches the expected identity. Restrict redirects, schemes, hosts, ports, and private addresses according to the deployment trust model.
Use capabilities safely
Select only supported algorithms, grants, token methods, and endpoints that local policy permits. Do not treat an advertised capability as approval to use it. Cache with a bounded lifetime, retain a safe last-known configuration when appropriate, and define key and endpoint rotation behavior.
Failure and residual risk
Server-side request forgery, malicious redirects, issuer mix-up, dynamic key-source selection, stale metadata, and partial rotation can expand trust. Metadata integrity does not prove that every advertised method is safe for the client. A compromised authorized issuer remains trusted until detected and removed.
Pomerium boundary
Pomerium uses configured identity-provider metadata as part of authentication. Operators own the trusted issuer and provider configuration. Upstream OAuth clients and resource servers must perform their own bounded discovery and validation.
Evaluation checklist
- What trusted identifier or URL starts discovery?
- Must the returned issuer or resource match exactly?
- Are redirect, scheme, host, port, and private-network access bounded?
- Does local policy restrict advertised algorithms and methods?
- Are caching, rotation, outage, and compromised-provider responses tested?
