Scope narrowing limits during refresh token rotation

Direct Answer

The OAuth 2.0 core specification (RFC 6749) does not guarantee that a client can request a reduced scope set during a refresh token rotation. Whether scope narrowing works, fails with an error, or is silently ignored depends entirely on the authorization server implementation.

What the Specification Says

RFC 6749 Section 6 states that the authorization server may issue a new access token with the same scopes as the original grant, or may honor a scope parameter in the refresh request if the server chooses to support it. The spec does not require servers to accept scope reduction, nor does it define a standard error code for a client that attempts to downgrade privileges during refresh.

Observed Server Behaviors

• Silent ignore: Many providers (including Google, Microsoft Identity Platform, and older Okta configurations) return an access token containing the originally granted scopes regardless of the scope parameter sent in the refresh request.
• Explicit rejection: Some servers (Auth0 with strict scope enforcement, Keycloak with certain policies, PingFederate) respond with invalid_scope when the requested scope is not a subset of the original grant, or invalid_request when the parameter is present but not supported.
• Conditional acceptance: A few implementations (newer Okta, ForgeRock AM with specific policies) honor a reduced scope parameter only when the refresh token was issued with a policy allowing scope downgrade.

Error Responses You Might See

There is no single standard error. If the server rejects the request, the JSON error response will typically use one of:

• invalid_scope — the requested scope is invalid, unknown, or not a subset of the original grant
• invalid_request — the scope parameter is not supported on the token endpoint
• unauthorized_client — the client is not permitted to reduce scopes (less common)

If the server silently ignores the parameter, you will receive a 200 OK with an access token whose scope claim (or introspection response) matches the original grant.

Verification Steps for Your Environment

1. Obtain a refresh token with a broad scope set (e.g., read write admin).
2. Call the token endpoint with grant_type=refresh_token and scope=read (a strict subset).
3. Decode the returned access token (JWT) or call the introspection endpoint and compare the scope claim against the original grant.
4. If the response is an error, note the error code and error_description.

One Diagnostic Detail Needed

Which authorization server (and version, if self-hosted) are you targeting? The exact behavior — and whether scope narrowing can be enabled via configuration — varies by product (Keycloak, Auth0, Okta, Azure AD, Ping, custom implementations). Knowing the server lets me point to its specific documentation or configuration knobs.