# Découverte d'authentification

> How an agent finds its way past a 401: RFC 9728 protected-resource metadata, RFC 8414 server metadata, PKCE and dynamic registration.

Cette vérification représente 1 % du score.

*Ces guides de correction sont rédigés en anglais.*

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.

---

<a id="not-found"></a>

## 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.

---

<a id="no-authorization-servers"></a>

## 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"]
```

---

<a id="invalid-issuer"></a>

## 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.

---

<a id="no-resource"></a>

## 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.

---

<a id="no-server-metadata"></a>

## 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"]
}
```

---

<a id="incomplete-server-metadata"></a>

## 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.

---

<a id="no-pkce"></a>

## 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"]
```

> **S256, not plain**
>
> The
>
> plain
>
>  method sends the verifier unhashed and protects against nothing an attacker who can see the redirect cannot already do.

---

<a id="no-registration"></a>

## 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"
```

---

Représentation Markdown de https://axrush.com/guides/auth-discovery