Auth-Discovery

This check only applies to a site that offers something an agent can call: an API description, an MCP server, or a commerce profile. If none of that surface needs credentials, there is nothing here to fix and the check reports not applicable.

When it does need them, the problem is that an agent meeting a 401 has nowhere to look. It cannot read your documentation. The discovery chain exists so it does not have to:

• /.well-known/oauth-protected-resource (RFC 9728) says which authorization server guards this resource.
• /.well-known/oauth-authorization-server (RFC 8414) or the OpenID equivalent says which endpoints that server has.

No authorization metadata found

You publish a callable surface and no machine-readable way to authenticate against it. Publish RFC 9728 metadata naming your authorization server:

GET /.well-known/oauth-protected-resource

{
  "resource": "https://api.example.com",
  "authorization_servers": ["https://auth.example.com"]
}

If everything you offer is public, this is nothing to fix.

Metadata that names no server

The document exists and omits authorization_servers, so it says a token is needed without saying where to get one. That is the one fact the file exists to carry.

"authorization_servers": ["https://auth.example.com"]

An issuer that is not an absolute https URL

Entries must be absolute and must be https. A relative path or an http origin cannot be resolved into a discovery request, and the chain stops before it starts.

No canonical resource URI

Without resource, a client cannot request a token audienced for you specifically. Tokens are then either too broad or rejected, and neither failure is legible from the outside.

The chain stops at the server

Your resource metadata names an authorization server, and that server publishes nothing. An agent now knows who to ask and not what to ask for. Publish RFC 8414 metadata, or OpenID discovery, at the issuer:

GET https://auth.example.com/.well-known/oauth-authorization-server

{
  "issuer": "https://auth.example.com",
  "authorization_endpoint": "https://auth.example.com/authorize",
  "token_endpoint": "https://auth.example.com/token",
  "code_challenge_methods_supported": ["S256"]
}

Server metadata missing an endpoint

The document is there and a required field is not. An OAuth client cannot complete a flow without issuer, authorization_endpoint and token_endpoint, so a missing one is the same outcome as a missing file, arrived at later.

No PKCE advertised

Agents are public clients: they hold no secret. PKCE is the only thing standing between an intercepted authorization code and a stolen session, and a server that does not advertise it leaves a careful client no way to know it is supported.

"code_challenge_methods_supported": ["S256"]

No way for a client to register itself

Without dynamic registration or Client ID Metadata Documents, every new agent needs a person to register it first. That is a queue, not an integration, and it is the step where most agent connections are abandoned.

"registration_endpoint": "https://auth.example.com/register"