What is Scope?
Also called OAuth Scope, Permission Scope.
A scope is a named permission requested during an authorization flow that bounds what an issued token may do. Scopes appear as space separated strings in the authorization request, are shown to the user on the consent screen, and are enforced by the resource server on every call. They express the principle of least privilege in access delegation.
Scope names are defined by each provider rather than by a universal standard, though many follow a recognizable pattern combining a resource and an action, such as reading messages or managing files. The authorization server records the granted set with the token, and the resource server rejects any call whose required scope is absent, typically with a forbidden status and an error describing what was missing.
Granted scopes may be narrower than requested. A user can decline part of a consent screen, and an administrator policy can trim the set further, so a client must inspect what it actually received rather than assuming its request was honored. Well behaved integrations degrade gracefully, disabling features whose scopes were denied instead of failing outright.
Requesting too much is a practical hazard as well as a security one. Broad scope requests raise the chance a user abandons the consent screen, may trigger a stricter review process from the provider, and enlarge the blast radius if a token leaks. Incremental authorization, asking for additional scopes only when a feature is first used, addresses this.
Scope is authorization, not identity, and it does not replace server side permission checks. A token scoped to write files still must be checked against whether that particular user may write that particular file. Scopes bound the delegation; they say nothing about record level access rules.
Key points
- Named permissions that bound what a token can do
- Provider specific names, shown on the consent screen
- Granted set can be narrower than requested
- Ask incrementally rather than requesting everything upfront
- Does not replace per-record authorization checks
In practice
An assistant integration needs to read a user's calendar and later to create events. At connection time it requests only the read scope, so the consent screen is short and low risk. When the user first asks it to book something, the integration starts a second authorization request adding the write scope. If the user declines, booking stays disabled while reading continues to work normally.