Category: OAuth & OIDC
Rich Authorization Requests
Also known as: RAR, OAuth 2.0 Rich Authorization Requests, authorization_details
Simply put
Rich Authorization Requests (RAR) is an extension to OAuth 2.0 that lets an application describe exactly what access it needs using structured data rather than simple, coarse permission labels. For example, instead of just asking for broad access, a client can specify the precise actions, resources, or limits it wants. This gives finer-grained control over what a user is being asked to authorize.
Formal definition
RAR is an OAuth 2.0 extension, standardized in RFC 9396, that introduces the authorization_details request parameter to carry fine-grained, structured authorization data in OAuth messages. Rather than relying solely on the space-delimited scope parameter, a client conveys one or more JSON objects, each typically including a type field and additional type-specific fields, to express the exact access being requested. As an authorization mechanism, RAR concerns what a client may be granted and does not itself perform user authentication; it is commonly used within flows such as the authorization code flow, where the resulting authorization data may be reflected in issued tokens. The specific structure and interpretation of each authorization_details object depend on the type definitions agreed upon in a given deployment or profile, so exact semantics are configuration- and API-dependent.
Why it matters
The traditional OAuth 2.0 scope parameter is a coarse instrument. A scope like payments or account.write conveys a broad category of access but cannot express constraints such as a specific payee, a transaction amount limit, or a single named resource. In deployments where the difference between broad and narrow access carries real financial or privacy consequences, payment initiation, healthcare records, or high-value administrative operations, this coarseness forces clients to request more than they need and leaves resource owners consenting to something vaguer than the actual intended action. RAR, standardized in RFC 9396, addresses this by letting a client describe the exact access it wants as structured JSON in the authorization_details parameter, enabling authorization decisions and consent prompts that reflect the specific action, resource, or limit at stake.
Who it's relevant to
API and platform architects
Architects designing APIs that require finer-grained authorization than scopes can express should evaluate RAR when access needs to be constrained to specific actions, resources, or limits. Because each authorization_details type is defined per deployment or profile, architects are responsible for specifying type structures and ensuring the authorization server and resource servers interpret them consistently.
OAuth 2.0 client developers
Developers integrating with authorization servers that support RFC 9396 can use the authorization_details parameter to request precisely the access an application needs rather than over-requesting through broad scopes. They should confirm which authorization_details types a given authorization server accepts, since semantics are API-dependent.
Authorization server and identity platform operators
Teams operating authorization servers must decide whether to support RAR, define which type values are recognized, and determine how authorization_details is validated and reflected in issued tokens. As RFC 9396 specifies, the parameter carries fine-grained data, so operators bear responsibility for validating that data against agreed type definitions.
Compliance and consent design leads
Because RAR allows requested access to be described in structured, specific terms, it can support consent experiences that show resource owners the precise action or resource being authorized rather than a broad category. This is relevant in regulated contexts where the granularity of consent matters, though the actual benefit depends on how each authorization_details type is defined and surfaced in the deployment.
Inside RAR
authorization_details parameter
A JSON array carried in the authorization request that expresses fine-grained authorization data, defined by the OAuth 2.0 Rich Authorization Requests specification (RFC 9396). It supplements or replaces the coarse-grained scope parameter when a request requires more structured detail than a scope string can convey.
type field
A required identifier within each authorization_details object that determines the schema and meaning of the remaining fields in that object. The client and authorization server must share an understanding of each type value, as the specification does not itself define specific type schemas.
Common data fields
The specification defines a set of optional, commonly used fields such as locations, actions, datatypes, identifier, and privileges. Whether and how these apply depends on the semantics associated with a given type, and their use is context-dependent rather than mandatory.
Delegated authorization scope, not authentication
RAR operates within OAuth 2.0, a delegated authorization framework. It refines what access is being requested and granted; it does not authenticate the end user. Authentication remains the responsibility of a separate mechanism such as OpenID Connect where user identity is needed.
Relationship to issued tokens
Authorization details that are granted are typically reflected in the resulting access token, either as claims within a self-contained token or as state referenced by an opaque token, so that a resource server can enforce the fine-grained permissions during runtime.
Common questions
Answers to the questions practitioners most commonly ask about RAR.
Does Rich Authorization Requests change OAuth 2.0 from an authorization framework into an authentication protocol?
No. RAR extends how a client expresses fine-grained authorization details in an OAuth 2.0 request via the authorization_details parameter, but it operates entirely within OAuth 2.0's delegated authorization model. It does not authenticate the end user. If you need user authentication, that remains the job of OpenID Connect layered on top of OAuth 2.0. RAR only enriches the description of what access is being requested; it says nothing about verifying who the user is.
Is RAR just a replacement for OAuth 2.0 scopes?
Not exactly. Scopes remain valid and RAR is generally intended to complement, not universally replace, them. Scopes express coarse-grained, mostly static permission sets as space-delimited strings, whereas RAR's authorization_details carries structured JSON objects that can express fine-grained, contextual, or transactional authorization data (for example a specific resource, action, or amount). In many deployments the two are used together, and whether you use scopes, authorization_details, or both depends on the authorization server's support and your use case.
How does a client structure an authorization_details request under RAR?
A client typically sends authorization_details as a JSON array of objects, where each object includes a type field identifying the authorization detail schema, along with additional fields defined by that type. The specific fields and their semantics depend on the type definitions agreed upon between the client, authorization server, and resource server. Exact field support and validation behavior vary by authorization server implementation, so consult the specific product's profile before designing request payloads.
How do authorization_details propagate into issued tokens, and how does the resource server consume them?
Depending on the authorization server configuration, the granted authorization_details may be reflected in the token response and, for self-contained tokens such as JWTs, embedded as a claim, or surfaced via token introspection for opaque tokens. The resource server (acting as the enforcement point) is responsible for validating the token and interpreting the authorization_details to make its access decision. Because a signed token guarantees integrity but not confidentiality, avoid placing sensitive detail in unencrypted self-contained tokens where that matters.
How does RAR interact with user consent at the authorization endpoint?
Because authorization_details can describe fine-grained or transaction-specific access, the authorization server may present consent tied to those specific details rather than to broad scopes. Whether and how granular consent is displayed depends on the authorization server's implementation and any applicable profile. The authorization server may also return a modified set of authorization_details reflecting what was actually granted, which can differ from what the client requested, so clients should not assume the request is honored verbatim.
What should teams verify before adopting RAR in a deployment?
Confirm that your authorization server, and any downstream resource servers, support the authorization_details parameter and the specific type schemas you intend to use, since support varies by vendor and version. Establish agreement on the type definitions across all parties, decide how granted details are conveyed (in-token versus via introspection), and consider token confidentiality if details are sensitive. Treat RAR as an authorization-request enrichment mechanism and keep identity governance concerns such as provisioning and access certification separate from this runtime request behavior.
Common misconceptions
RAR is a new authentication mechanism that verifies who the user is.
RAR is an extension to OAuth 2.0, a delegated authorization framework. It expresses what access is being requested with fine granularity and does not authenticate users. Authentication typically requires a separate layer such as OpenID Connect.
RAR fully replaces OAuth 2.0 scopes in every deployment.
RAR can supplement or, depending on the deployment, replace coarse-grained scopes for requests needing structured detail. In many implementations scopes and authorization_details coexist, and the exact interplay depends on the authorization server's configuration and the API's requirements.
The RAR specification defines the specific authorization_details types applications should use.
The specification defines the framework and some common fields but leaves the concrete type schemas to be agreed upon between clients and authorization servers, or defined by API-specific or ecosystem profiles. Interoperability depends on that shared agreement.
Best practices
Define and document the authorization_details type schemas your ecosystem uses, since the specification does not standardize specific types and interoperability depends on shared client and authorization server understanding.
Treat RAR strictly as an authorization mechanism and pair it with an authentication layer such as OpenID Connect where verified user identity is required, rather than relying on RAR for authentication.
Validate incoming authorization_details on the authorization server, rejecting unknown types and malformed structures rather than silently ignoring or downgrading requests.
Ensure granted authorization details are faithfully represented in issued tokens, and confirm that resource servers enforce them at runtime; remember that a signed token is not encrypted, so avoid placing sensitive detail in plaintext claims.
Decide deliberately how authorization_details and traditional scopes coexist in your deployment, and document the precedence and interaction rules to avoid ambiguity.
Reference RFC 9396 as the authoritative source and verify vendor support and profile behavior, since RAR handling can vary by authorization server implementation and configuration.
