Wiki · Concept · Last reviewed June 25, 2026

Rich Authorization Requests

Rich Authorization Requests are an OAuth 2.0 extension for carrying structured authorization details, giving agent systems a way to describe exact actions, resources, and constraints instead of hiding them inside broad scopes.

Category: Concept Updated: June 25, 2026 Tags: AI agents, authorization, OAuth, RAR, permissions, audit trails

Definition

Rich Authorization Requests, usually abbreviated RAR, are an OAuth 2.0 extension standardized in RFC 9396. The RFC was published in May 2023 by Torsten Lodderstedt, Justin Richer, and Brian Campbell. It defines the authorization_details parameter for carrying fine-grained authorization data in OAuth messages.

OAuth scopes are useful for broad categories such as profile read access or calendar write access. RAR is for cases where the request needs more structure: the action, resource location, data type, identifier, privilege, amount, recipient, path, or other API-specific field. The result is not magic consent. It is a machine-readable way to say what permission is being requested.

For AI agents, RAR matters because agent permissions often need to be itemized. "Write access" is too coarse for a system that may draft one support reply, update one ticket, send one payment, delete one file, or deploy one change.

How It Works

The authorization_details value is a JSON array of objects. Each object has a required type field, and that type determines which fields are allowed for the protected API. RFC 9396 defines common fields such as locations, actions, datatypes, identifier, and privileges, while leaving API-specific semantics to the authorization server and resource server.

The authorization server can use the details to ask for consent, decide whether to issue an access token, and communicate granted details to the client or resource server. RFC 9396 also registers authorization_details for JWT-based access tokens and token introspection, so the resource server can enforce more than a flat scope string when the deployment supports it.

RAR does not replace OAuth 2.0. It sits inside the OAuth framework defined by RFC 6749. It can also coexist with resource indicators from RFC 8707 and with the audience-restriction guidance in RFC 9700. Scope, audience, resource, client authentication, and token lifetime still matter.

Agent Context

An agent approval prompt should not merely say that a tool wants "files.write" or "payments.create." The useful question is which file, which operation, which recipient, which amount, which time window, and which actor. RAR gives OAuth deployments a standard place to put that structured request.

The Model Context Protocol is relevant because its HTTP authorization specification uses OAuth metadata and resource indicators. MCP security guidance also warns against token passthrough, a pattern where a client token is handed downstream and trust boundaries blur. RAR can support cleaner tool authorization when agent platforms and tool servers define clear authorization-detail types and enforce them.

The hard part is not JSON. The hard part is making the details real. If a model is tricked by prompt injection into asking for a destructive but well-formed authorization detail, RAR only records the shape of the request. Policy, review gates, least privilege, resource-server enforcement, and audit trails still decide whether the action is safe.

Governance and Safety

The governance value of RAR is that it can turn permission from a slogan into a record. A useful log should preserve the requested authorization details, the details actually granted, the user or policy approval, the resource server that enforced them, the token lifetime, and the final side effect.

The main failure mode is decorative detail. A consent screen can render a friendly summary while the underlying object grants broader action. A resource server can ignore fields it does not understand. An authorization server can accept vague or collision-prone type values. A client can ask for many objects at once until no human can meaningfully review the request.

Agent deployments should therefore treat RAR schemas as governance artifacts. Types should be documented, versioned, validated, and narrow enough for users, auditors, and resource servers to understand. High-impact fields such as recipient, amount, file path, external address, deletion target, deployment environment, and expiry should be visible in approval and audit views.

Defense Pattern

Source Discipline

Claims about Rich Authorization Requests should identify the exact authorization_details type, the fields requested, the fields granted, and the enforcement point. RAR should not be confused with OAuth Token Exchange, sender-constrained tokens, ordinary scopes, API keys, browser cookies, or consent as a legal conclusion.

Spiralist Reading

Spiralism reads RAR as a discipline of naming power before it moves. The machine asks not for vague trust, but for an object: this action, on this resource, under these constraints.

That object is not enough by itself. It must be rendered to people, enforced by systems, and preserved for review. Otherwise structured permission becomes another beautiful interface over ambient authority.

Open Questions

Sources

Return to Wiki