Fix guide · info · openid_configuration_exposed

OIDC discovery document exposed

Why it matters

OpenID Connect discovery (RFC 8414) standardises a single URL — /.well-known/openid-configuration — that describes everything a client needs to integrate with your identity provider. If you operate an OIDC provider, you must publish this document. If you don't, you shouldn't.

What the document reveals:

• issuer — your IdP's canonical URL (often a subdomain that's otherwise hard to find: auth.example.com, login.internal.example.com).
• token_endpoint, authorization_endpoint — the exact paths to OAuth flows.
• jwks_uri — where your public signing keys live.
• scopes_supported — every scope your IdP recognises, including any custom internal ones like admin:all or internal:debug.
• grant_types_supported — which OAuth grants you've enabled (clients can craft flows accordingly).
• token_endpoint_auth_methods_supported — whether you accept basic auth, JWT-assertion, mTLS, etc.

None of this is a vulnerability. All of it is useful for an attacker mapping your auth surface before trying anything else.

When this finding fires unexpectedly: you're not running an IdP, but something in your stack (a misconfigured reverse proxy, a "smart" routing rule, an embedded library exposing its config) is serving the discovery doc at your origin. Investigate which subsystem is responding and decide whether it should be.

How to fix it

If you are intentionally running an OIDC provider:

• Confirm the document only lists endpoints you intend to expose. Custom scopes named internal:* or admin:* should not appear publicly — they reveal what privileged operations exist.
• Confirm grant_types_supported lists only the flows you've actually enabled. Listing password or urn:ietf:params:oauth:grant-type:device_code when you don't use them implies "yes please try this" to attackers.
• Lock down the JWKS endpoint to serve only your currently-active signing keys. Old keys should rotate out, not stay listed indefinitely.

If you didn't intentionally publish this:

1. Find which subsystem is responding. Common culprits: Keycloak, Authentik, Auth0 self-host, Supabase Auth, NextAuth.js (/api/auth/openid-configuration or similar), or a reverse proxy with a default upstream.
2. Block the path at the edge if you don't actually need it published. CF Pages _headers/redirect rules can return 404 for /.well-known/openid-configuration.
3. If you do need it published but the issuer URL listed is internal-only (https://internal.example.com), update the issuer config so the document advertises the public URL instead.

Did vibecheck flag this on your app?

If you reached this page from a vibecheck inspection report, the redacted match in your scan output is the exact string we found in your bundle. After applying the fix above, run the inspection again — the finding should clear.