--- title: Rich Authorization Requests (RAR) in the AuthPlayground description: Explore how Rich Authorization Requests express fine-grained operations that OAuth policies can evaluate in the AuthPlayground. component: identity-for-ai page_id: identity-for-ai:protocols:authplayground-rar canonical_url: https://developer.pingidentity.com/identity-for-ai/protocols/authplayground-rar.html llms_txt: https://developer.pingidentity.com/identity-for-ai/llms.txt docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md revdate: 2026-08-24T07:38:08Z keywords: ["Identity for AI", "OAuth 2.0 protocols", "rich authorization requests", "RAR", "fine-grained authorization", "enterprise AI", "AuthPlayground"] section_ids: the-rar-model: The RAR model authorization-details-structure: Authorization details structure the-authplayground-implementation: The AuthPlayground implementation step-1-send-authorization-details: "Step 1: Send authorization details" the-user-can-authorize-a-specific-operation: The user can authorize a specific operation step-2-exchange-the-authorization-code: "Step 2: Exchange the authorization code" step-3-enforce-authorization-at-the-resource-server: "Step 3: Enforce authorization at the resource server" how-rar-relates-to-other-concepts: How RAR relates to other concepts giving-policy-better-information: Giving policy better information rar-isnt-limited-to-human-initiated-ai: RAR isn't limited to human-initiated AI rar-and-scopes-are-complementary: RAR and scopes are complementary rar-and-par-work-together-naturally: RAR and PAR work together naturally key-takeaways: Key takeaways --- # Rich Authorization Requests (RAR) in the AuthPlayground Constraining what AI is allowed to do. Sarah asks the company's AI assistant to prepare her for a meeting with Apex Logistics. She has broad access across customer systems and can read opportunities, update records, access multiple accounts, and perform other actions required by her role. The AI assistant's task is much narrower and requires only a specific set of information. What the AI assistant needs to do isn't the same as what Sarah can do. RAR ([RFC 9396](https://datatracker.ietf.org/doc/html/rfc9396)) provides a way for an OAuth client to describe a specific operation it wants to perform. ## The RAR model OAuth scopes are useful for describing general capabilities. An application can request something such as `customer.read`. Some authorization decisions need more context, such as: ``` Action: Read Customer: Apex Logistics Data: Relevant account context ``` RAR adds the `authorization_details` parameter to OAuth, allowing clients to describe authorization requirements in a structured, machine-readable form. Authorization details can include type, actions, resource information, and other constraints. These details provide more precise information than a flat scope string alone. ### Authorization details structure An authorization detail is a structured JSON object. Its fields depend on the type of authorization requested. An enterprise AI API example might look like this: ```json { "type": "customer_information", "actions": ["read"], "identifier": "apex-logistics" } ``` RAR gives the API a structured way to describe what is being requested. Instead of asking only for `customer.read`, the request describes which customer, which action, and any other constraints that matter to policy. ## The AuthPlayground implementation **Entities involved**: Client application, IdP (authorization server), resource server The AuthPlayground demonstrates the [Rich Authorization Requests](https://www.authplayground.dev/flows/rar) flow in three steps: 1. Send the authorization request with `authorization_details`. 2. Exchange the authorization code. 3. Enforce authorization at the resource server. The playground uses a payment initiation example that makes fine-grained authorization easy to see. ### Step 1: Send authorization details The client begins an OAuth authorization request. Alongside the usual OAuth and Proof Key for Code Exchange (PKCE) parameters, it sends `authorization_details`. The request looks like this: ```json GET /idp/authorize response_type=code client_id=playground-demo-client scope=openid code_challenge= code_challenge_method=S256 authorization_details= ``` The decoded authorization details include the specific operation requested: ```json [ { "type": "payment_initiation", "instructedAmount": { "amount": "123.50", "currency": "USD" }, "creditorName": "Merchant Inc", "creditorAccount": { "iban": "DE75512108001245126199" } } ] ``` Compared with a broader permission such as `payment`, the structured request tells the authorization system much more. This is the value of RAR. The authorization request describes the specific operation that needs authorization. #### The user can authorize a specific operation Because authorization details are structured, the authorization server can evaluate the exact operation requested. Instead of just asking if the application is allowed to make payments, the request asks if the application can make a $123.50 USD payment to Merchant Inc at a specific destination account. This is a more meaningful authorization decision. The user authorizes a particular operation rather than granting an abstract capability with little context. ### Step 2: Exchange the authorization code The client exchanges the authorization code using the standard Authorization Code flow with PKCE. The playground request is: ```json POST /idp/token Content-Type: application/x-www-form-urlencoded grant_type=authorization_code code= redirect_uri= client_id=playground-demo-client code_verifier= ``` The response contains an access token. The decoded token contains: ```json { "sub": "demo-user@example.com", "scope": "openid", "client_id": "playground-demo-client", "authorization_details": [ { "type": "payment_initiation", "instructedAmount": { "amount": "123.50", "currency": "USD" }, "creditorName": "Merchant Inc", "creditorAccount": { "iban": "DE75512108001245126199" } } ] } ``` Notice that the scope is `openid`, but the token also carries the richer authorization context. This level of detail can't be expressed with a flat scope string. ### Step 3: Enforce authorization at the resource server The client calls the protected resource using the access token: ```json GET /rs/resource Authorization: Bearer ``` The resource server validates the token and the authorization information associated with it. The response shows that the same structured authorization context is available at the protected resource: ```json { "message": "Access granted to protected resource", "user": "demo-user@example.com", "authorization_details": [ { "type": "payment_initiation", "instructedAmount": { "amount": "123.50", "currency": "USD" }, "creditorName": "Merchant Inc", "creditorAccount": { "iban": "DE75512108001245126199" } } ] } ``` The resource server isn't working from a generic statement that the user can make payments. It has structured context describing the authorized operation. This gives downstream policy something more precise to enforce. ## How RAR relates to other concepts ### Giving policy better information Fine-grained authorization becomes essential when AI can take actions rather than simply retrieve information. Consider three requests against the same Apex Logistics account: * Reading the opportunity is low risk * Updating the forecast is higher risk * Deleting the opportunity is high risk These operations require different policy decisions. Structured authorization details give policy enough context to distinguish between them. A `read` action might be allowed automatically. An update requires additional controls. A destructive operation requires approval or is denied entirely. RAR doesn't define business policies or a meeting preparation authorization model. It gives the authorization system a precise description of the operation to enable policies to make better decisions. The API then defines what these authorization details mean. ### RAR isn't limited to human-initiated AI Sarah is a useful example, but RAR isn't inherently tied to a human user. Autonomous workloads also need fine-grained authorization. For example, an autonomous action agent might request a specific operation, sending `authorization_details` to the authorization server to obtain constrained authorization. The agent operates under its own machine authority and authorization details help establish what the agent is allowed to do, whether it's acting for a person or autonomously. ### RAR and scopes are complementary RAR doesn't mean scopes disappear. Authorization details and scopes describe different parts of the authorization model. Scopes present broad capabilities, while authorization details describe fine-grained authorization requirements. An API might use scopes, authorization details, or both depending on how its authorization model is designed. The important distinction is that RAR provides richer structure when a flat capability string isn't enough. ### RAR and PAR work together naturally As authorization requests become richer, they can also become larger and more sensitive. This is where [Pushed Authorization Requests (PAR)](authplayground-par.html) complement RAR. PAR defines how the authorization request reaches the authorization server, pushing the request directly to the server before the browser redirect. RAR defines what is being requested. The two protocols solve different parts of the authorization problem. ## Key takeaways RAR doesn't establish identity. It gives the authorization system a structured description of the requested operation. RAR authorizes the specific operation, not just the caller. The authorization server evaluates the structured request, the access token carries the resulting authorization context, and the resource server enforces what's authorized.