---
{
  "title": "OAuth scopes and delegated permissions",
  "summary": "OAuth scopes describe a requested or granted range of delegated access.",
  "topic": "foundations",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    4
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: OAuth2",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

OAuth scopes describe a requested or granted range of delegated access. Their exact meaning depends on the resource service and its policies. A token bearing a scope still requires appropriate audience checks and object-level authorization; broad consent can create long-lasting exposure.

## A practical example

A reporting integration requests read-only access to the records it needs rather than permission to modify every account resource. The resource API also verifies that each requested record falls within the delegating user's authorized data.

## What to check

Document scope semantics, request minimal permissions, inspect granted consent, and plan revocation. Test whether resource checks remain effective when a token has a broad scope.

## A common pitfall

A scope name is not a universal guarantee of limited access. Different services interpret scopes differently, and a broad grant does not remove record ownership requirements.

## Think it through

Does a read scope permit reading any customer's record?

**Answer:** No. The resource server must still enforce the delegating identity's permissions and the token's intended audience.

## A scope needs a precise meaning

A fictional research portal offers integrations a scope named reports.read. That name alone leaves important questions unanswered: does it cover reports owned by the user, reports shared with their team, archived reports, or every report in the organization? The resource service should document the answer and enforce it consistently across list, detail, and export operations.

Scopes describe a grant boundary, while object authorization determines whether a particular record falls inside that boundary for the delegating identity. A broad read scope should not erase a user's normal record permissions. Likewise, a narrow-looking scope can still be high impact if it permits bulk exports or access to sensitive categories.

Consent language should explain practical effects rather than exposing only internal scope strings. 'Read reports you can access' gives a user more context than an unexplained token claim. Request permissions when they are needed, and avoid collecting broad grants in advance simply because a future feature might use them.

## Compare two integration designs

For a paper exercise, design a dashboard that displays report titles and a separate tool that edits report content. List the smallest permissions each requires and the records each may access. Explain whether one integration should hold both grants or whether separate clients provide a clearer boundary.

Review grants over time. An integration's owner may leave, the application's purpose may change, or a previously useful permission may no longer be necessary. Provide a revocation path and understand the lifetime of credentials issued under the grant. The meaningful measure of least privilege is the access the integration can actually exercise, including downstream endpoints, rather than the number of scope names displayed on a consent screen.

## Related concepts

- [[oauth-security]]
- [[least-privilege]]
- [[authorization]]