OAuth RAR and rich authorization for finer-grained API governance

At a glance

What this is: OAuth RAR is an OAuth 2.0 extension that lets clients request structured, context-specific permissions instead of relying on coarse scope strings.

Why it matters: For IAM and NHI practitioners, RAR shows how coarse authorization models break down when APIs, service accounts, and agents need transaction-level limits.

👉 Read Raidiam's technical overview of OAuth RAR and layered authorization

Context

OAuth scopes were designed for broad permission categories, not for the detailed, transaction-specific requests common in modern API ecosystems. That creates a governance gap for NHI and agent-driven workflows, where access often needs to be limited to a specific action, resource, amount, or device state rather than a generic API family. In those environments, authorization detail matters as much as authentication.

OAuth RAR addresses that gap by moving the decision context into the request itself, which gives authorization servers more to evaluate and resource servers more precision to enforce. For IAM teams, the question is not whether finer-grained authorization is desirable. The question is whether the surrounding policy, registration, and enforcement controls are mature enough to use it safely. The broader NHI governance lesson aligns with the Ultimate Guide to NHIs.

OAuth RAR also exposes a familiar identity problem in a more structured form: if clients can ask for richer permissions, the ecosystem must govern which clients are allowed to ask in the first place. That is a typical failure point in non-human identity programs, where request precision improves only if registration, trust boundaries, and consent handling are already disciplined.

Key questions

Q: How should security teams implement OAuth RAR in enterprise APIs?

A: Start by defining which client types are allowed to request each authorization_details type, then validate those types consistently at the authorization server and the resource server. Pair the model with PAR or JAR for request integrity, and keep consent text aligned with the exact action being requested. That turns RAR into a controlled authorization pattern rather than a syntax change.

Q: When does OAuth RAR reduce risk, and when can it increase it?

A: RAR reduces risk when it replaces broad scopes with tightly constrained request semantics and when client registration is strict. It can increase risk when ecosystems treat detailed requests as inherently trustworthy, because a compromised client can still ask for dangerous actions if policy and validation are weak. Precision helps only when governance matches it.

Q: What is the difference between OAuth scopes and OAuth RAR?

A: Scopes are coarse permission labels, usually expressed as simple strings. OAuth RAR uses structured JSON to describe the exact action, resource, or context being requested, which gives authorization servers and users more precision. The tradeoff is operational complexity, because every participant has to interpret the same request semantics correctly.

Q: How can organisations keep rich authorization requests from becoming over-permissioned?

A: Use roles, pre-registration, and policy validation to limit which clients can request specific rich authorization types. Then enforce least privilege at the resource server so the token cannot exceed what was approved. If the request can be expressed but not safely bounded, the ecosystem is still over-trusting the client.

Technical breakdown

How OAuth RAR changes authorization semantics

OAuth RAR, or Rich Authorization Requests, extends OAuth 2.0 with the authorization_details parameter. Instead of a flat scope string such as payments.read, the client submits a JSON array that describes the exact action, resource, and often the business context of the request. That allows the authorization server to assess a payment amount, a target account, a device function, or a data type as part of the decision. The model is more expressive, but also more dependent on consistent interpretation across the ecosystem.

Practical implication: Practitioners must validate that authorization servers and resource servers interpret the same RAR types and fields the same way.

Why PAR and JAR matter for rich authorization requests

RAR improves expressiveness, but the request still has to travel securely. Pushed Authorization Requests, or PAR, move the authorization payload to the authorization server over a back-channel, while JWT-secured Authorization Requests, or JAR, protect the request contents with signed structure and integrity controls. Together, they reduce tampering risk and prevent clients or intermediaries from injecting or rewriting authorization intent. In practice, RAR without request integrity controls can create a false sense of precision if the request itself is not protected.

Practical implication: Security teams should pair RAR with PAR or JAR wherever request integrity and confidentiality matter.

Layered authorization: roles, scopes, and rich requests

RAR works best as one layer in a broader authorization stack. Roles can decide which applications are even allowed to request certain rich authorization types, scopes can define broad categories, and RAR can specify the transaction-level details. That layered model is especially relevant in regulated ecosystems such as open banking, healthcare, and IoT, where ecosystem membership and accreditation matter as much as the requested permission. Without a role gate, a client may still craft a detailed request for an action it should never have been able to ask for.

Practical implication: Use role metadata and pre-registration controls to limit which clients can request sensitive RAR types.

Threat narrative

Attacker objective: The attacker wants to obtain precise, high-value authorization for an action that should have been constrained by registration, role, or consent controls.

1. entry via a client that can craft or relay overly detailed authorization requests without proper ecosystem gating.
2. escalation through acceptance of rich request fields that are not tightly validated by the authorization server or resource server.
3. impact through unauthorized initiation of sensitive actions such as payments, privileged device operations, or scoped data access.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OAuth RAR is not a replacement for governance, it is a governance amplifier. Rich Authorization Requests improve the precision of what a client can ask for, but they do not solve trust, registration, or enforcement on their own. If ecosystems treat structured requests as a security control by themselves, they will simply move ambiguity from the scope string into the JSON payload. Practitioners should treat RAR as an authorization language, not an authorization decision.

Layered authorization is the right model for non-human identities that operate inside regulated APIs. Roles can constrain who may request a class of action, scopes can narrow the category, and RAR can define the exact transaction. That sequence is more defensible than relying on one mechanism to do all three jobs. The practical consequence is that IAM teams need to design policy boundaries before they design request syntax.

Fine-grained access only scales when client onboarding is disciplined. RAR makes it easier to express intent, which also makes it easier to express unsafe intent if client registration is weak. This is where NHI governance meets API governance: application identity, accreditation, and request validation must be aligned or the platform will over-trust detailed requests. Teams should treat client eligibility as a first-class control.

Rich authorization exposes the identity blast radius problem more clearly. When access is granted at transaction granularity, the real question becomes how far a compromised client can go before the request is rejected. That makes least privilege more measurable, but also more operationally demanding. Practitioners should use RAR to reduce standing power, not to rationalize broader access under a more elegant syntax.

Contextual consent is only useful when the underlying semantics are stable. A clear consent screen improves user understanding, but the control still depends on the exact meaning of actions, datatypes, and identifiers remaining consistent across participants. In distributed ecosystems, semantic drift becomes a security issue. The practical takeaway is to standardise request types and review them like policy objects, not like UI text.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• 91% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to Ultimate Guide to NHIs.
• For a broader NHI control baseline, review Ultimate Guide to NHIs , Key Challenges and Risks alongside RAR policy design.

What this signals

Rich authorization will not fix weak identity hygiene. If clients can request precise access but the ecosystem cannot revoke, validate, and segment that access quickly, the net risk remains high. With 91.6% of secrets still valid five days after notification, according to Ultimate Guide to NHIs, the operational problem is not expression. It is control durability.

Identity blast radius is the concept practitioners should track next. RAR can narrow what a client asks for, but it also makes the boundaries of compromise easier to define when controls are mature. That should push teams to align API authorization design with OWASP Non-Human Identity Top 10 concerns around over-privilege and request governance.

Teams should expect more pressure to connect authorization semantics with lifecycle controls, especially where service accounts and application identities can request business actions on behalf of users. The next programme decision is whether policy objects, registration metadata, and review processes are strong enough to support that precision without creating an ungoverned approval path.

For practitioners

• Define approved RAR types for each client class Map each application or service account to the specific authorization_details types it may request, then reject any request outside that registration profile. Use pre-approval for high-risk actions such as payment initiation or privileged device control.
• Pair RAR with PAR or JAR Require Pushed Authorization Requests or JWT-secured Authorization Requests for flows where request integrity, confidentiality, or anti-injection controls matter. This prevents unauthorised rewriting of the authorization payload in transit.
• Build resource-server enforcement tests around exact semantics Verify that resource servers enforce the same action, location, identifier, and datatype semantics that the authorization server approved. Add negative tests for missing, malformed, or broadened authorization_details fields.
• Use role metadata as a gate before rich requests Attach metadata to application roles so only accredited clients can request sensitive RAR categories. This limits the blast radius of compromised clients and stops over-privileged request crafting at the edge.

Key takeaways

• OAuth RAR improves authorization precision, but it does not replace trust, registration, or enforcement controls.
• The main governance value of RAR is reduced scope sprawl, provided resource servers enforce the same semantics that authorization servers approve.
• Enterprises should treat rich authorization as part of NHI governance and API policy design, not as a standalone security control.

Key terms

• OAuth Rich Authorization Requests: OAuth Rich Authorization Requests, or RAR, is an OAuth 2.0 extension that lets a client describe the exact access it wants in structured JSON instead of a broad scope string. The result is more context-aware authorization, but only if servers and policy owners validate the semantics consistently.
• Authorization_details: Authorization_details is the JSON payload field used by OAuth RAR to express the precise action, resource, or business context being requested. It gives authorization servers richer input for decisions, but it also increases the need for strict schema validation and ecosystem alignment.
• Pushed Authorization Requests: Pushed Authorization Requests move the authorization payload to the authorization server over a back-channel before the browser or front channel is used. That reduces tampering and leakage risk, which is especially useful when the request contains sensitive or highly specific authorization data.
• Layered authorization: Layered authorization is a control pattern that combines roles, scopes, and request-level detail so no single mechanism carries the full security burden. It is useful in NHI-heavy ecosystems because it separates who may ask from what they may ask for and what is ultimately enforced.

Deepen your knowledge

OAuth RAR, layered authorization, and non-human identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing API controls for service accounts or agentic clients, it is a practical next step.

This post draws on content published by Raidiam: OAuth RAR and layered authorization for fine-grained access control. Read the original.