---
title: "OAuth Authorization Server discovery · Sitebulb Labs"
description: "RFC 8414 metadata lets agents discover how to obtain authorization."
url: https://labs.sitebulb.com/docs/checks/protocol-discovery/oauth-discovery/
---

# OAuth Authorization Server discovery

RFC 8414 metadata lets agents discover how to obtain authorization.

- Category

  [Protocol discovery](https://labs.sitebulb.com/docs/checks/protocol-discovery)

- Standard

  Recommended

## What it checks

The extension looks for authorization server metadata at these paths, in order, and stops at the first that answers:

1. `/.well-known/oauth-authorization-server` (RFC 8414)
2. `/.well-known/openid-configuration` (OpenID Connect Discovery)

A path counts when it returns a successful, non-empty JSON response: the `Content-Type` mentions `json`, or the body starts with `{` or `[`. The fields inside are not validated.

## Results

| Status   | When                                 |
| -------- | ------------------------------------ |
| **Pass** | Either path returns a JSON document  |
| **N/A**  | Neither path returns a JSON document |

## How to fix

If your API is protected by OAuth, publish the authorization server’s metadata at `/.well-known/oauth-authorization-server` so an agent can find the endpoints it needs without being told:

```json
{
  "issuer": "https://auth.example.com",
  "authorization_endpoint": "https://auth.example.com/authorize",
  "token_endpoint": "https://auth.example.com/token",
  "response_types_supported": ["code"]
}
```

Most identity providers already serve `/.well-known/openid-configuration`; the check finds it on the origin you scan, so it only passes if the metadata is on that origin.

Related: [OAuth Protected Resource metadata](https://labs.sitebulb.com/docs/checks/protocol-discovery/oauth-protected-resource).