OAuth and OpenID Connect Discovery Metadata for Agent Authorization Flows
Lets an AI agent acting on a user's behalf find your login endpoints automatically and request the right permissions.
What this signal tests
We check whether your site publishes OAuth 2.0 Authorization Server metadata (per RFC 8414) at /.well-known/oauth-authorization-server, or OpenID Connect Discovery metadata at /.well-known/openid-configuration. The document must include the required claims: issuer, authorization_endpoint, token_endpoint, jwks_uri, and response_types_supported.
Why it matters for your visibility in AI
When an AI agent acts on behalf of a user - booking a flight, posting on their behalf, accessing their account - it has to log in as that user, but only with the permissions the user agrees to. OAuth Discovery metadata is how the agent finds your login endpoints automatically, without a human integrator. It is also the foundation that the Model Context Protocol (MCP) authorization flow is built on; agents calling MCP servers expect OAuth Discovery to be present. The practical consequence: if you operate user accounts and an AI agent tries to act for one of your users, missing Discovery metadata means the agent either cannot log in at all or has to embed hard-coded URLs which break the moment you rotate them. Identity providers like Auth0, Okta, and Keycloak publish this metadata automatically; if you run your own auth, you need to publish it yourself.
Pass criteria at a glance
| Criterion | Passes when |
|---|---|
| Either metadata document present with all required fields. |
How we test it
Our scanner fetches both well-known paths - /.well-known/oauth-authorization-server and /.well-known/openid-configuration - and parses the response as JSON. It verifies each required field is present and points at a real URL: issuer (your identifier), authorization_endpoint (where users approve access), token_endpoint (where tokens are issued), jwks_uri (where signing keys are published), and response_types_supported. Either document satisfies the test.
Show technical detection method
GET both well-known paths; validate JSON includes required fields per RFC 8414 / OIDC Discovery 1.0.
If your site fails: how to fix it
- If you use an off-the-shelf identity provider - Auth0, Okta, Keycloak, AWS Cognito, Azure AD - confirm the discovery document is enabled and exposed on your own domain or the IdP's tenant URL.
- If you run a custom OAuth or OIDC server, publish the discovery document per RFC 8414 and OpenID Connect Discovery 1.0; the work to do this is best done by a developer who can read both specifications.
- Ensure the document is reachable over public HTTPS without authentication - the whole point is that an agent that has not yet logged in can discover where to log in.
- Verify every URL inside the document actually responds; broken endpoints in a discovery document cause agents to fail silently and choose competitors who advertise correctly.
- Keep the document in sync if you rotate signing keys, change endpoints, or add new grant types; agents cache discovery for short windows and re-fetch regularly.
Quick facts
| Maturity | ESTABLISHED |
|---|---|
| Weight | medium |
| Category | Agent Actions |
Primary sources
Related signals
Frequently asked questions
We do not have user accounts - do we still need this?
No. OAuth Discovery is only relevant if you operate user accounts that an agent might log in to. Sites with no login surface - pure content, brochure sites, anonymous APIs - can ignore this signal entirely. The scanner will still flag it but the practical impact is zero.
Will this matter in 2026 or is it years away?
It matters now. Every MCP server that handles user data needs OAuth Discovery, and MCP servers shipped through 2024 and 2025. ChatGPT's connectors, Claude's connectors, and most enterprise agent platforms already use Discovery to authorize against third-party accounts.
Does this cost anything to implement?
If you use Auth0, Okta, Keycloak, or any major IdP, it is enabled by default at no extra cost. If you run custom auth, the implementation cost is a few developer days. There are no licensing fees; both RFC 8414 and OIDC Discovery are open standards.
Does publishing endpoints expose us to attack?
No. The Discovery document only lists endpoints that need to be public anyway - users have to reach the authorization endpoint to log in. Hiding the URL does not provide meaningful protection. Defence belongs in the auth flow itself: PKCE, short-lived tokens, scope checks.
Run your own scan
Run a free scan and see how your site grades across all 155 AI-readiness signals.