deeratna.co

RFC 8414 metadata is a JSON file at /.well-known/oauth-authorization-server that tells software where your sign-in endpoints live: where to send a user to authorise, where to exchange tokens. We requested it and found none. This only applies if your site has accounts or an API that third parties connect to.

Agents acting on a user’s behalf (booking, purchasing, managing an account) need permission first, and OAuth is how they get it without ever seeing a password. The metadata file is how they discover your endpoints programmatically instead of a developer hand-configuring each integration. No file means every agent integration starts with manual setup, so most never start.

1. If you run an OAuth authorization server (Auth0, Keycloak, Okta, or your own), enable its metadata endpoint; most providers publish RFC 8414 metadata with a setting.
2. Serve or proxy it at /.well-known/oauth-authorization-server on this domain.
3. If your site has no user accounts or API, this check simply isn’t your priority; it is one reason it carries a small weight.

• Open yoursite.com/.well-known/oauth-authorization-server and confirm JSON with an "issuer" field matching your domain.
• Hit Re-scan above: "OAuth authorization metadata" flips to PASS.

• Don’t publish metadata naming endpoints that don’t answer; broken discovery is worse than none, because clients trust the file over their own guesses.
• Don’t copy another provider’s metadata as a template and leave their URLs in it. Every URL in the file must be yours.

RFC 9728 metadata is the companion file at /.well-known/oauth-protected-resource: it describes your API as a protected resource, naming which authorization servers guard it and which scopes it understands. We requested it and found none. Like the authorization-server file, it applies to sites with an API behind sign-in.

An agent that finds your API needs to learn "what permission do I ask for, and who grants it" before it can make a single call. This file answers exactly that, by machine. Without it the answer lives only in human documentation, which agents integrate from slowly and wrongly.

1. Publish a JSON document at /.well-known/oauth-protected-resource naming your resource identifier, the authorization servers that protect it, and the scopes it accepts.
2. Keep it consistent with the RFC 8414 file: the authorization server named here should be the one whose metadata you publish there.
3. If you have no protected API, deprioritise this; the check exists for the sites that do.

• Open yoursite.com/.well-known/oauth-protected-resource and confirm it returns your JSON.
• Hit Re-scan above: "OAuth resource metadata" flips to PASS.

• Don’t list scopes your API doesn’t enforce. Declared-but-ignored scopes teach integrators that your security documentation is decorative.