---
title: "What is RFC 9278, \"Protected Resource Metadata Discovery\"?"
source: Panaversity Learn Agentic AI
source_url: https://github.com/panaversity/learn-agentic-ai
licence: Apache-2.0
domain: agentic-ai
subdomain: panaversity-agentic
date_added: 2026-04-25
---

# What is RFC 9278, "Protected Resource Metadata Discovery"?

RFC 9278, "Protected Resource Metadata Discovery," defines a simple method for a client application to figure out **how to get authorization** to access a protected resource, like an API.

In short, it specifies a way for an API (the "Resource Server") to tell a client application **where to find its own instruction manual**—the "Authorization Server" (AS) and its associated metadata.

### The Problem it Solves

Imagine a client application wants to access data from an API at `https://api.example.com/data`. To do this, it needs an access token. However, the client doesn't know:

  * Which Authorization Server (AS) issues tokens for this specific API?
  * What type of tokens are needed?
  * What scopes or permissions are required to access `/data`?

The client needs a standardized way to "discover" this information without having it hardcoded.

-----

### The Solution: The `as_uri`

RFC 9278 provides a simple solution. When the client makes an unauthenticated request to the protected resource (`https://api.example.com/data`), the Resource Server (the API) can deny the request with a `401 Unauthorized` status code.

Crucially, the server includes a `WWW-Authenticate` HTTP header that contains the **`as_uri`** (Authorization Server URI) parameter.

Here is an example of what that header might look like:

```http
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer as_uri="https://auth.example.com"
```

This `as_uri` tells the client exactly where to go (`https://auth.example.com`) to find the authorization server's metadata.

-----

### Discovering the Metadata

Once the client has the `as_uri`, it can make a standard request to that URL to fetch the AS's metadata. This metadata document typically follows the format defined in [RFC 8414](https://www.rfc-editor.org/info/rfc8414) ("OAuth 2.0 Authorization Server Metadata") and contains all the information the client needs to proceed with authorization, such as:

  * **`issuer`**: The identifier of the Authorization Server.
  * **`authorization_endpoint`**: The URL to send the user to for login.
  * **`token_endpoint`**: The URL the client uses to exchange an authorization code for an access token.
  * **`scopes_supported`**: A list of all permissions the AS can grant.
  * **`response_types_supported`**: The types of authorization flows supported (e.g., code, token).

By using this discovery process, a client application can dynamically configure itself to interact with any API that supports this standard, making the system more flexible and decoupled.
