What is the difference between OAuth scopes and OAuth RAR?

Why This Matters for Security Teams

OAuth scopes and OAuth RAR both shape consent, but they do not solve the same problem. Scopes are intentionally blunt, which makes them easy to implement but hard to audit when the request is nuanced. RAR adds structure for precision, which is increasingly important for NHIs that act on behalf of workflows, services, and agents. That matters because 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, so vague permissions can quickly become invisible risk. The OWASP view of NHI risk in the OWASP Non-Human Identity Top 10 also reinforces that over-broad machine access is a recurring failure pattern.

The practical issue is not whether scopes are “bad” and RAR is “good”. It is whether the authorisation model matches the request. A broad scope can be acceptable for a low-risk integration, while a structured RAR request is better when the resource, action, or context needs to be explicit for review, approval, or policy evaluation. In practice, many security teams encounter scope sprawl only after an OAuth app has already been widely adopted and misused.

How It Works in Practice

Scopes are usually fixed strings such as read:accounts or write:files. They are coarse labels that help the authorisation server decide what token claims to issue. OAuth RAR, by contrast, lets the client describe the request in JSON so the authorisation server can see the actual intent, target resource, and other details before granting access. That makes it closer to intent-based authorisation than to classic role mapping.

For practitioners, the main difference is operational. With scopes, the policy question is often “does this app need this broad capability?” With RAR, the question becomes “does this specific request match policy, context, and user or operator consent?” That precision can help with JIT approval flows, step-up checks, and conditional access, especially when an integration needs to request something exceptional rather than an always-on privilege.

• Use scopes for stable, low-variance permissions that are easy to reason about.
• Use RAR when the request needs to name the resource, action, or transaction context.
• Evaluate the request at runtime, not only at registration time, so the policy engine can inspect the full context.
• Treat RAR as a control input, not just a nicer consent screen.

This is especially relevant for machine-to-machine access and delegated workflows, where “what the app wants” is more important than “what the app always has.” The Ultimate Guide to NHIs — What are Non-Human Identities shows why machine identities need tighter lifecycle and visibility controls, and the Ultimate Guide to NHIs — Key Challenges and Risks explains how broad permissions amplify exposure. These controls tend to break down when applications hard-code assumptions about a fixed scope vocabulary because the RAR request and the policy engine no longer share the same semantics.

Common Variations and Edge Cases

Tighter request modelling often increases implementation and governance overhead, requiring organisations to balance precision against interoperability. That tradeoff is real: RAR can improve review quality, but only if clients, authorisation servers, and downstream policy systems interpret the structure consistently. Current guidance suggests treating RAR as an emerging precision tool rather than a universal replacement for scopes.

One edge case is legacy ecosystems. Many APIs, gateways, and SDKs still expect coarse scopes and will not understand structured requests without custom work. Another is consent UX: if the request is too detailed, users may approve without understanding it, which weakens the security benefit. A third is policy drift. If the JSON request schema changes faster than the enforcement logic, the organisation can create gaps that look precise on paper but behave inconsistently in production.

For NHIs, the most useful pattern is often hybrid. Use scopes for baseline entitlements, then use RAR for exceptional or high-impact actions that need runtime evaluation. That aligns better with the direction described in the Salesloft OAuth token breach and the Dropbox Sign breach, where OAuth abuse became consequential once tokens and app permissions were able to move beyond the original intent.

Related resources from NHI Mgmt Group

• What is the difference between passwordless authentication and full ransomware resistance?
• What is the difference between adaptive authentication and Zero Standing Privilege?
• What is the difference between passwordless authentication and simply hiding the password?
• What is the difference between symmetric and asymmetric encryption for IAM use cases?