Refresh Token Grant

The refresh token grant (grant_type=refresh_token) lets a client obtain a new access token (and sometimes a rotated refresh token) without sending the user through login and consent again. It applies only after an interactive grant — authorization code or CIBA — already issued a refresh token.

Refresh is not a separate toggle in the Console; it is part of the token response from user-delegated flows.

How it works

1. The client previously completed an authorization code or CIBA flow and stored the refresh token from the token response.
2. When the access token expires (or is about to), the client sends POST to the token endpoint with grant_type=refresh_token, refresh_token, and client_id. Confidential clients also send client_secret. Public clients refresh without a secret (the app must have been created as a public client).
3. Descope validates the refresh token and consent record. If consent was revoked or expired, refresh fails and the user must authorize again.
4. Descope returns a new access token. Refresh does not re-prompt for scopes the user already granted unless consent expired.

A refresh can keep or narrow the scopes on the new access token, but it can never add scopes. When the client sends a scope parameter with the refresh request, Descope issues only the requested scopes that the refresh token was originally granted, and drops any others (RFC 6749 §6). To get a scope the user never granted, the client has to send the user through the authorization code flow again.

Select any step to see what happens. The user isn’t involved, but the refresh only works while their consent is still valid.

Implement

See Using Inbound Apps → Refreshing Access Tokens for confidential and public client examples.

Related

• Authorization code grant
• CIBA
• Consent flows