RFC 9396: OAuth 2.0 Rich Authorization Requests
CIAM Weekly
SubscribeSign in
RFC 9396: OAuth 2.0 Rich Authorization Requests
Dan Moore<br>Mar 30, 2026
Share
Heya,<br>RFC 9396 defines a new OAuth 2.0 request parameter called authorization_details that lets clients express fine-grained authorization requirements using structured JSON, rather than the flat string-based scope parameter.<br>This RFC, also known as the Rich Authorization Requests (RAR) spec, was published as an IETF Standards Track document in May 2023, so is a few years old.<br>If you’ve ever tried to express “please authorize a payment of exactly $123.50 to this specific bank” using OAuth scopes, you’ve felt the problem this spec addresses.<br>Scopes are great for coarse-grained access: “read profile,” “write files”. But they weren’t designed to carry transaction-level detail. RAR handles this.<br>The Core Mechanism
Instead of (or alongside) the scope parameter, clients include an authorization_details parameter in their authorization request. It’s a JSON array of objects, where each object has a required type field that identifies the kind of resource or API being accessed, plus whatever additional fields that API needs.<br>The spec also defines a set of common reusable fields:<br>locations
actions
datatypes
identifier
privileges
API designers can use these as building blocks.<br>So a payment initiation request might include the transfer amount, currency, creditor name, and IBAN (which is fancy for “a bank account number”). A file access request might specify which paths get read vs. write.<br>These details get surfaced to the user at consent time so they know exactly what they’re approving. A user sees not just “this app wants payments access” but “this app wants to send $123.50 to Merchant A.”<br>RAR is Not Just for the Consent Screen
RAR isn’t only about showing the user better information on the consent screen. The granted authorization_details can be embedded directly in a JWT, which means resource servers (RS) can enforce policy at a much more granular level than coarse-grained scopes allow.<br>The RS can check not just “does this token allow payments?” but “does this token authorize a transfer to this specific account for this specific amount?” Any request that doesn’t match can be rejected.<br>There’s also a meaningful security property at the token endpoint: a client can’t broaden its access between the authorization step and the token request.<br>When a RAR request comes in, the authorization server (AS) can validate that any authorization_details in the token request are a subset of what was actually authorized.<br>Finally, the locations field lets authorization details be bound to specific resource server URIs. This is similar to the resource parameter, but can be used in combination. Combined with sender-constrained tokens like DPoP, this approach tightens what a stolen token can be used to access. With the right RS configuration, such tokens are valid only at the declared endpoint, for the declared purpose, with the declared parameters.<br>Who’s Using It
The spec’s examples are very payment-centric. But adoption has spread beyond the payments space:<br>OpenID for Verifiable Credentials (OID4VC) uses authorization_details with a type of openid_credential as the mechanism for wallets to request specific credential types during issuance. This is infrastructure for digital identity wallets.
Auth0 and other major identity providers have added native support for RAR in their authorization server implementations.
The RFC’s appendix includes detailed examples for eHealth and tax data APIs, drawn from real Norwegian government requirements, but these appear to be illustrative rather than confirmed production deployments. The CAMARA project (a Linux Foundation telco API initiative) explored using RAR to bind OAuth scopes to GDPR purposes in a single request, but as of early 2026 that remains a feature proposal rather than a shipped specification.<br>RAR is a well-designed spec with decent authorization server support and a clear value proposition. But outside of payments and verifiable credentials, widespread API-level adoption is still nascent.<br>Implementation Considerations
A few things worth knowing if you’re evaluating or implementing RAR.<br>First, the spec recommends using Pushed Authorization Requests (PAR, RFC 9126) alongside RAR. This is because the authorization_details payload can get large and URL-encoding a complex JSON array into a GET parameter is ugly and brittle. PAR solves this issue by posting the request body to the AS first and getting back a short reference URI.<br>Next, type values should be unambiguous. The spec recommends ASCII strings. For APIs deployed across multiple servers, a collision-resistant namespace like a URI you control (https://yourdomain.example/payment_initiation) is the safe choice.<br>Importantly, RAR doesn’t replace a policy engine deployed at the AS and RS.<br>RAR is a communication mechanism. It’s a way to carry rich intent from client to AS...