A scope names access that a client requests when obtaining a bearer token through OAuth 2.0 or OpenID Connect. A user may grant or deny requested scopes, and the identity provider may limit which scopes a client can receive. The resulting access token can contain some—or none—of the scopes requested. section 25.6
A scope does not enforce access by itself. The API decides what the scope means and applies an authorization policy to endpoints that need it. Authentication first validates the bearer token; authorization then checks the endpoint’s requirements against the authenticated user. section 25.6 section 25.2
Require a scope to edit recipes
An API can define a policy that requires the token’s `scope` claim to contain `recipe.edit`, then apply that policy to recipe-editing endpoints. For local testing, `dotnet user-jwts create --scope recipe.edit` adds a scope claim to a generated JWT. Creating the claim does not, on its own, protect an endpoint; the API must require it. section 25.6 section 25.4.2
Figure 25.12 Authorizing a request to a minimal API endpoint. The routing middleware selects an endpoint that is protected by an authorization requirement. The authentication middleware decodes and verifies the bearer token, creating a ClaimsPrincipal, which the authorization middleware uses along with the endpoint metadata to determine whether the request is authorized.
Follow a protected request from endpoint selection through bearer-token validation to the authorization decision. The endpoint’s policy is where a required scope can be checked. section 25.6
