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.
Expanded Definition
OAuth Rich Authorization Requests, commonly called RAR, extends OAuth 2.0 by letting a client request narrowly defined permissions in structured JSON rather than vague scope strings. The goal is better context, stronger policy evaluation, and fewer overbroad grants, especially where an NIST Cybersecurity Framework 2.0 approach demands explicit access control. In practice, RAR is used when a client needs to describe not just what it wants to do, but the target, amount, action, or resource characteristics that make the request intelligible to the authorization server.
Definitions vary across vendors because RAR is a protocol extension, not a complete policy model. Some platforms treat it as a user-consent enhancement, while others use it as part of machine-to-machine authorization and delegated administration. That distinction matters in NHI security because the same structured request can be either tightly governed or dangerously permissive depending on how the server validates the JSON object and maps it to policy. The most common misapplication is treating RAR as a cosmetic replacement for scopes, which occurs when teams accept richer request syntax without enforcing matching server-side authorization rules.
Examples and Use Cases
Implementing RAR rigorously often introduces policy complexity, requiring organisations to weigh fine-grained authorization against the cost of validating more request attributes, more decision paths, and more failure cases.
- An API client requests access to a specific account, invoice batch, or data set instead of a broad read/write scope, reducing excess privilege when policy engines interpret the JSON correctly.
- An Salesloft OAuth token breach style incident shows why overly broad delegated access becomes dangerous when an attacker can reuse a token beyond the original business intent.
- A finance workflow asks for limited approval rights over a named transaction type, which helps separate routine operational access from higher-risk actions that should require human review.
- Machine identities in CI/CD or integration platforms can request temporary access to a defined resource set, but only if the authorization server evaluates resource semantics, not just client identity.
- A Dropbox Sign breach illustrates the operational danger of delegated integrations that were not constrained tightly enough to match the actual business function.
Why It Matters in NHI Security
RAR matters because NHIs rarely operate with a single, static permission profile. Service accounts, agents, and API clients often need contextual access that changes by transaction, data owner, or time window. When RAR is well implemented, it supports least privilege and improves auditability. When it is not, structured requests can create a false sense of control while broad underlying grants remain untouched. That is especially important in environments where third-party OAuth apps already reduce visibility, and where NHI governance must account for secrets, tokens, and delegated trust relationships at scale.
NHI Mgmt Group research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which means request detail alone does not solve governance unless approvals, logging, and revocation are also in place. RAR supports better decisions, but only when paired with policy enforcement, entitlement review, and monitoring for abnormal consent patterns. It should be read alongside the assurance principles in NIST Cybersecurity Framework 2.0, especially where access decisions must be traceable and defensible.
Organisations typically encounter the real impact after a token is abused or an integration is exposed, at which point OAuth Rich Authorization Requests becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | RAR affects how NHI clients request and receive narrowly scoped access. |
| NIST CSF 2.0 | PR.AC-4 | RAR supports least-privilege access decisions tied to specific resources and actions. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires explicit, context-aware access decisions that RAR can express. |
Validate structured authorization requests and reject any client ask that exceeds approved business intent.
