Scope

No. In OAuth 2.0 (RFC 6749 §3.3), scope is a mechanism for expressing and limiting the access privileges granted to an access token; it governs delegated authorization, not authentication. Determining who the user is requires the authentication layer added by OpenID Connect, where requesting the reserved openid scope triggers issuance of an ID token per OpenID Connect Core §3.1.2.1. Scope by itself, in a plain OAuth 2.0 flow, tells the authorization server what access is being requested, not who the requesting principal is.

Not exactly. Scope is an OAuth 2.0/OIDC construct that bounds what an issued token may be used to request; it is expressed as space-delimited strings in the authorization and token requests. Roles (RBAC) and fine-grained permissions typically live in the resource server's or authorization system's access control model and are evaluated at enforcement time. In many deployments a scope represents a coarse-grained capability that the resource server then maps to finer-grained authorization decisions, but the OAuth 2.0 specification does not define scope values or mandate any particular access control model. The mapping between scopes and roles or permissions is deployment-specific.

Under RFC 6749 §3.3, scope is expressed as a case-sensitive, space-delimited list of strings whose meanings are defined by the authorization server. OpenID Connect Core reserves certain values such as openid, profile, email, address, and phone, which map to defined sets of claims. Beyond those reserved values, scope strings are typically defined by the API provider or authorization server and documented out of band. The authorization server may grant a scope narrower than what the client requested, and per the specification it should inform the client when the granted scope differs from the requested scope.

A common practice is to define scopes narrowly enough that clients request only the access they need, rather than defining a few broad scopes that over-grant. Depending on your API design, this may mean separating read from write access, or segmenting scopes by resource type or sensitivity. Because the authorization server may issue a narrower scope than requested, designing granular scopes lets both the server and resource operators enforce tighter boundaries. Keep in mind that scope is generally coarse-grained; fine-grained, contextual, or data-row-level decisions are typically better handled by the resource server's authorization logic (for example an ABAC or PBAC policy) rather than by proliferating scope values indefinitely.

At the enforcement point, the resource server typically validates the presented access token and then checks whether the scope associated with that token permits the requested operation. For self-contained tokens such as signed JWTs, the scope claim can be read after signature validation; note that a signed token is integrity-protected but not necessarily confidential unless it is also encrypted. For opaque tokens, the resource server generally relies on token introspection or an equivalent lookup with the authorization server to obtain the granted scope. Whether scope enforcement alone is sufficient depends on your design; many deployments treat scope as one input to a broader authorization decision made by a policy decision point.

In OpenID Connect, requesting the openid scope signals that authentication is desired and that an ID token should be issued alongside the access token, per OpenID Connect Core §3.1.2.1; additional reserved scopes like profile or email influence which claims are returned. The scope requested at authorization time typically bounds the access token's granted privileges and, in most deployments, also constrains what a refresh token can later obtain. Behavior such as whether scopes can be narrowed on token refresh, and how scope maps to ID token claims versus UserInfo endpoint responses, varies by authorization server configuration and profile, so consult your provider's documentation.