OAuth 2.0 access-token expiration and least-privilege scope enforcement

Token lifetime vs. scope granularity

OAuth 2.0 access tokens carry both an expiration timestamp (exp claim) and a set of granted scopes. Resource servers must reject expired tokens, but the specification leaves open how servers should handle tokens that are still valid yet request scopes exceeding the client's current least-privilege assignment.

Unresolved behavior

When a token's scopes are broader than the client's current role permits—due to role changes after token issuance—servers face a decision: reject the request immediately, downgrade the effective scopes to the intersection, or rely on the token's original authorization. RFC 6749 and RFC 7662 do not mandate a specific approach, and implementations differ.

This affects systems that rotate roles frequently or enforce just-in-time access, where a token issued under a privileged role may outlive the role assignment.

Specific questions

1. Do major resource-server implementations (e.g., Spring Authorization Server, Keycloak, Azure AD) reject or scope-downgrade such tokens by default?
2. Is there a standardized introspection response field that conveys the effective scopes after role changes?
3. What configuration knobs exist to enforce strict least-privilege alignment without shortening token lifetimes?