OIDC Discovery Misconfiguration: Issuer and Metadata Pitfalls
OpenID Connect clients often bootstrap trust from a discovery URL. They fetch /.well-known/openid-configuration, learn the authorization endpoint, token endpoint, and JWKS URI, then treat that metadata as gospel. If an attacker can influence which discovery document is fetched—or if the client ignores issuer checks—the rest of OIDC math collapses.
This is configuration hunting with protocol teeth.
Fetch and compare metadata
Locate discovery documents for every environment in scope: production, staging, partner IdPs, and tenant-specific issuers. Compare issuer, authorization_endpoint, token_endpoint, jwks_uri, and supported response_types.
Red flags:
issuerthat does not match the URL you fetched- JWKS hosted on a different, weaker domain
- Mixed HTTP and HTTPS endpoints
- Tenant metadata that accepts arbitrary
issuerquery parameters
Some multi-tenant products build the discovery URL from a user-supplied IdP name. Try a tenant value that points at a metadata host you control. If the app fetches your document and later trusts tokens signed by your JWKS, you own the login.
Staging discovery documents reachable from production clients deserve their own note even before token forgery. Mixed environments are how keys and client IDs leak sideways.
Client checks that must not be optional
A correct client still validates the issuer in ID tokens against the expected value, verifies signatures against the discovered JWKS, and enforces aud. Discovery makes that easier—it does not replace it.
Test whether the application pins the issuer after first login or re-resolves metadata every time. Dynamic re-resolution plus a poisoned DNS or SSRF-able metadata URL is a nasty combination. Stay inside scope: use an IdP you own and accounts you own.
Authorization code flows need exact redirect_uri matching. Discovery might advertise a correct endpoint while the client registration still allows a loose redirect. Mix both tests; attackers chain them. Algorithm confusion between the discovery id_token_signing_alg_values_supported list and what the token endpoint actually accepts is worth a controlled probe too.
Practical bounty proofs
Controlled IdP takeover is the gold standard: victim starts SSO, client loads attacker metadata, attacker signs an ID token for the victim's email or subject. Only perform this with test users and a disposable tenant.
Weaker but still valid findings include staging discovery documents reachable from production clients, JWKS without key rotation hygiene paired with algorithm confusion elsewhere, or error messages that disclose client secrets during OIDC handshake failures.
Fix guidance worth including
Pin trusted issuers, validate discovery issuer matches the configured value, fetch metadata only over TLS to allowlisted hosts, cache JWKS with key ID awareness, and reject tokens before discovery completes successfully. Disable per-request IdP URL overrides unless you are building an enterprise federation product with strict admin approval.
The OpenID discovery specification is short; quote the issuer rule in your report so triage does not dismiss it as theoretical. Your screenshot of the poisoned metadata fetch plus a canary login is the part that lands. Document whether private_key_jwt or client_secret_post is required. A discovery doc advertising stronger auth while the token endpoint still accepts a leaked basic secret is worth a separate note.