OAuth Scopes Explained

What a scope is

A scope is a named permission that a client asks for, such as reading a particular kind of resource or performing a specific action against it. The access token that results from the flow is limited to the scopes that were actually granted, and the resource server enforces those limits on every call the token is used for.

Scopes are what turn a single, uniform token type into a flexible and fine-grained permission system. Without them, every token would carry the same blanket access; with them, two tokens issued by the same provider can permit entirely different things. On the Merion API, requesting only the scopes you genuinely need keeps each integration tightly bounded and makes its capabilities easy to reason about, both for you and for anyone reviewing what an application can do.

Requesting and granting

The client lists the scopes it wants on the authorisation request, declaring up front what access it is seeking. The user — or, in machine-to-machine flows, a configured system policy — then decides whether to grant them. Importantly, the token that is finally issued reflects what was actually granted, which may be a subset of what was requested rather than the full list.

This means your code cannot simply assume that every scope it asked for was approved. It must handle the case where fewer scopes come back than were requested, degrading gracefully or prompting the user rather than failing in a confusing way when a later call is rejected. Designing for partial grants from the outset is far less painful than discovering the gap in production when a particular permission turns out to have been declined.

Scopes and least privilege

Scopes are the primary way you apply least privilege in practice, turning an abstract principle into concrete configuration. A reporting tool should request read-only scopes and nothing more; a tool that never deletes data should never hold a delete scope in the first place. Narrow scopes directly shrink the consequences of a leaked token, because a token can only ever do what its scopes permit.

It is tempting to request broad scopes to avoid having to change anything later, but that convenience trades away real security for a small saving in effort. It is safer to start narrow and add a scope when a genuine need actually arises. We treat this principle in depth in Least Privilege for API Access, which pairs naturally with thoughtful scope selection on every integration.

Scopes and consent

For user-facing flows, scopes drive the consent screen the user is shown: they see, ideally in plain and specific language, exactly what the application is asking permission to do on their behalf. Requesting fewer, clearly named scopes makes that consent meaningful and considered, rather than an overwhelming wall of permissions that the user reflexively accepts without reading.

Over-requesting scopes "just in case" is a genuine anti-pattern: it alarms thoughtful users, widens your risk surface, and can even cause people to abandon the flow entirely when the request looks disproportionate to the task. Minimal, well-described scopes signal that an application respects the data it is touching. Learn more about how this fits the wider picture in Consent and Authorization.