# Ultraresearch Synthesis: OAuth 2.1 Authorization Server Metadata & Security Requirements

Workers: 8 parallel web searches + 4 document fetches
Waves: 2 (initial saturation + targeted section extraction)
Sources: 6 primary (RFC 8414, draft-ietf-oauth-v2-1-15, RFC 9700, RFC 9126, RFC 8705, RFC 7662)
Verifications: Cross-referenced across RFC 8414 txt, OAuth 2.1 draft HTML/txt/markdown, RFC 9700 txt

## Executive Summary

OAuth 2.1 (draft-ietf-oauth-v2-1-15, March 2026) consolidates RFC 6749, RFC 6750, RFC 8252, RFC 9700, and browser-based-app best practices into a single standards-track specification. It makes previously optional security extensions—especially PKCE—mandatory, removes insecure grant types (Implicit, Resource Owner Password Credentials), and mandates exact redirect URI matching. RFC 8414 defines the authorization server metadata format and registry; OAuth 2.1 references it as the discovery mechanism but does not redefine its fields. RFC 9700 (Security BCP) provides the threat model and mitigation requirements that OAuth 2.1 normatively incorporates.

## 1. REQUIRED Fields (RFC 8414 Section 2)

Per RFC 8414, the following metadata values are REQUIRED in the `oauth-authorization-server` metadata response:

- **`issuer`** — The authorization server's issuer identifier. MUST be an `https` URL with no query or fragment components. MUST exactly match the URL used to fetch the metadata (Section 3.3).
- **`authorization_endpoint`** — URL of the authorization endpoint. REQUIRED unless no grant types are supported that use the authorization endpoint.
- **`token_endpoint`** — URL of the token endpoint. REQUIRED unless only the implicit grant type is supported.
- **`response_types_supported`** — JSON array of supported OAuth 2.0 `response_type` values (e.g., `["code"]`).

## 2. RECOMMENDED / SECURITY-CRITICAL Fields

The following are not strictly REQUIRED by RFC 8414 but are strongly RECOMMENDED for a secure OAuth 2.1 deployment:

- **`scopes_supported`** — RECOMMENDED. JSON array of supported scope values.
- **`jwks_uri`** — OPTIONAL but highly RECOMMENDED. URL of the JWK Set document (MUST use `https`). Required for clients to validate server signatures and for asymmetric client auth.
- **`code_challenge_methods_supported`** — OPTIONAL in RFC 8414, but OAuth 2.1 makes PKCE mandatory. Therefore, publishing this field (containing at least `["S256"]`) is RECOMMENDED so clients can detect PKCE support (RFC 9700 Section 2.1.1; OAuth 2.1 Section 4.1.1).
- **`grant_types_supported`** — OPTIONAL (defaults to `["authorization_code", "implicit"]`). In OAuth 2.1, should reflect only supported grants (e.g., `["authorization_code", "client_credentials", "refresh_token"]`). Note: OAuth 2.1 removes implicit, so the default is misleading for pure 2.1 servers.
- **`token_endpoint_auth_methods_supported`** — OPTIONAL (defaults to `["client_secret_basic"]`). For highest security, servers SHOULD advertise asymmetric methods such as `private_key_jwt` and `tls_client_auth` (RFC 9700 Section 2.5).
- **`token_endpoint_auth_signing_alg_values_supported`** — OPTIONAL, but MUST be present if `private_key_jwt` or `client_secret_jwt` is advertised. SHOULD support `RS256`; `none` MUST NOT be used.
- **`revocation_endpoint`** / **`revocation_endpoint_auth_methods_supported`** / **`revocation_endpoint_auth_signing_alg_values_supported`** — OPTIONAL. If revocation is supported, auth method metadata follows the same rules as the token endpoint.
- **`introspection_endpoint`** / **`introspection_endpoint_auth_methods_supported`** / **`introspection_endpoint_auth_signing_alg_values_supported`** — OPTIONAL. RFC 9701 (JWT Response for Token Introspection) and RFC 7662 require authenticated callers; metadata should reflect supported auth methods.
- **`pushed_authorization_request_endpoint`** — Defined by RFC 9126 (PAR). RECOMMENDED for highest security to prevent request tampering and large-URI issues.
- **`require_pushed_authorization_requests`** — Boolean (RFC 9126). If `true`, the AS accepts authorization request data only via PAR.

## 3. Security Requirements Mandatory in OAuth 2.1

### 3.1 PKCE (Proof Key for Code Exchange)
- **Authorization servers MUST support `code_challenge` and `code_verifier`** (OAuth 2.1 Section 4.1.1).
- **Clients MUST use PKCE** for all authorization code flows, and **authorization servers MUST enforce their use** except under conditions described in Section 7.5.1 (authorization code injection). Even then, enforcing PKCE is still RECOMMENDED.
- **`S256` is Mandatory To Implement (MTI)** on the server. Clients capable of using `S256` MUST use it. `plain` is permitted only if the client cannot support `S256` for technical reasons and knows the server supports `plain` (via metadata or out-of-band).
- The AS MUST mitigate PKCE downgrade attacks: a token request containing `code_verifier` must be accepted only if `code_challenge` was present in the authorization request (RFC 9700 Section 2.1.1; OAuth 2.1 Section 7.5).

### 3.2 Removed / Deprecated Features
- **Implicit grant (`response_type=token`)** is **omitted** from OAuth 2.1 (Section 10.1). Servers should not support it; clients must not use it.
- **Resource Owner Password Credentials grant** is **omitted** from OAuth 2.1 (RFC 9700 Section 2.4; incorporated into OAuth 2.1). MUST NOT be used.

### 3.3 Redirect URI Handling
- **Exact string matching** is REQUIRED when comparing redirect URIs (OAuth 2.1 Section 2.3.1; RFC 9700 Section 2.1). The only exception is for **localhost loopback URIs of native apps**, where the port may vary (Section 8.4.2).
- The `redirect_uri` parameter in the **token request is now REQUIRED** if the `redirect_uri` was included in the authorization request (OAuth 2.1 Section 10.2). This closes a loophole where attackers could swap redirect URIs during code exchange.
- Authorization servers MUST require registration of the **complete redirect URI including the path** (OAuth 2.1 Section 2.3.1).

### 3.4 Refresh Token Security
- For **public clients**, refresh tokens MUST be either **sender-constrained** (e.g., DPoP, mTLS) or use **refresh token rotation** (one-time use) (OAuth 2.1 Section 4.3.3; RFC 9700 Section 2.2.2).
- If refresh tokens are issued, they MUST be bound to the scope and resource servers as consented by the resource owner (OAuth 2.1 Section 4.3.3).

### 3.5 Bearer Token Transmission
- Bearer tokens MUST NOT be passed in the **query string of URIs** (OAuth 2.1 Section 5.1). Only Authorization header or form-encoded body parameter are permitted.

### 3.6 Transport Security
- **TLS is mandatory** for all OAuth protocol URLs (must use `https`) except native-app loopback redirects (OAuth 2.1 Section 1.5).
- TLS certificates MUST be checked per RFC 9110 Section 4.3.4.
- TLS 1.3 (RFC 8446) is the most recent version at time of writing; TLS 1.2 is the minimum generally accepted.

### 3.7 Client Authentication
- It is **RECOMMENDED to use asymmetric cryptography** for client authentication, such as:
  - **Mutual TLS (`tls_client_auth`)** — RFC 8705
  - **Private Key JWT (`private_key_jwt`)** — RFC 7521 / RFC 7523
- When asymmetric methods are used, the AS does not need to store sensitive symmetric keys, reducing leakage risk (RFC 9700 Section 2.5).

### 3.8 Sender-Constrained Access Tokens
- Authorization and resource servers **SHOULD** use sender-constraining mechanisms such as **DPoP (RFC 9449)** or **mTLS (RFC 8705)** to prevent misuse of stolen tokens (OAuth 2.1 Section 1.4.3; RFC 9700 Section 2.2.1).

### 3.9 Authorization Server Mix-Up Mitigation
- When a client interacts with multiple ASes, a defense against mix-up attacks is REQUIRED. The `iss` parameter in the authorization response (RFC 9207) SHOULD be used (RFC 9700 Section 2.1; OAuth 2.1 Section 7.15).

## 4. Complete Set of Endpoints and Auth Methods (OAuth 2.1 Best Practices)

| Endpoint | Specification | Client Auth Method | Notes |
|---|---|---|---|
| **Authorization Endpoint** | OAuth 2.1 Section 3.1 | None (user-agent facing) | MUST NOT support CORS. MUST use exact redirect URI matching. |
| **Token Endpoint** | OAuth 2.1 Section 3.2 | `client_secret_basic` (default), `client_secret_post`, `private_key_jwt`, `tls_client_auth`, `none` for public clients | Asymmetric auth RECOMMENDED. |
| **Token Introspection** | RFC 7662 | Any token-endpoint auth method, or a dedicated RS access token | RFC 9701 mandates authenticated callers; MUST NOT allow unauthenticated introspection. |
| **Token Revocation** | RFC 7009 | Same as token endpoint (`client_secret_basic` default) | |
| **Pushed Authorization Request (PAR)** | RFC 9126 | Same as token endpoint | RECOMMENDED. Returns `request_uri` used at authorization endpoint. |
| **Device Authorization** | RFC 8628 | Client auth at device endpoint | For input-constrained devices. |
| **Dynamic Client Registration** | RFC 7591 | Varies (often initial access token or reg access token) | |
| **JWKS URI** | RFC 8414 | None (public keys) | Used by clients to fetch AS signing keys. |

## 5. Differences Between OAuth 2.0 and OAuth 2.1 Affecting Implementation

| Feature | OAuth 2.0 (RFC 6749) | OAuth 2.1 (draft-15) |
|---|---|---|
| **PKCE** | Optional (RFC 7636 extension) | **Mandatory** for all authorization code flows |
| **Implicit Grant** | Supported | **Removed / Omitted** |
| **Password Grant (ROPC)** | Supported | **Removed / Omitted** |
| **Redirect URI Matching** | Flexible (prefix, wildcard, pattern matching common) | **Exact string matching required** (except localhost port) |
| **Redirect URI in Token Request** | Not required | **Required** if present in auth request |
| **Bearer Token in Query String** | Allowed | **Prohibited** |
| **Refresh Tokens (Public Clients)** | No special constraints | **Must be sender-constrained or rotated** |
| **Client Types** | Complex definitions (confidential/public based on ability to maintain cred secrecy) | Simplified: based on whether client has credentials |
| **S256** | Optional PKCE method | **Mandatory To Implement** |

## Sources (Primary)

1. **RFC 8414** — OAuth 2.0 Authorization Server Metadata (June 2018) — https://www.rfc-editor.org/rfc/rfc8414.txt
2. **draft-ietf-oauth-v2-1-15** — The OAuth 2.1 Authorization Framework (March 2026) — https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-15.txt
3. **RFC 9700** — Best Current Practice for OAuth 2.0 Security (January 2025) — https://www.rfc-editor.org/rfc/rfc9700.txt
4. **RFC 9126** — OAuth 2.0 Pushed Authorization Requests — https://datatracker.ietf.org/doc/rfc9126/
5. **RFC 8705** — OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
6. **RFC 7662** — OAuth 2.0 Token Introspection
7. **RFC 9701** — JSON Web Token (JWT) Response for OAuth Token Introspection