Microsoft identity platform refresh tokens
When a client acquires an access token to access a protected resource, the client also receives a refresh token. The refresh token is used to obtain new access/refresh token pairs when the current access token expires. Refresh tokens are also used to acquire extra access tokens for other resources. Refresh tokens are bound to a combination of user and client, but aren't tied to a resource or tenant. As such, a client can use a refresh token to acquire access tokens across any combination of resource and tenant where it has permission to do so. Refresh tokens are encrypted and only the Microsoft identity platform can read them.
Before reading through this article, it's recommended that you go through the following articles:
Refresh token lifetime
Refresh tokens have a longer lifetime than access tokens. The default lifetime for the refresh tokens is 24 hours for single page apps and 90 days for all other scenarios. Refresh tokens replace themselves with a fresh token upon every use. The Microsoft identity platform doesn't revoke old refresh tokens when used to fetch new access tokens. Securely delete the old refresh token after acquiring a new one. Refresh tokens need to be stored safely like access tokens or application credentials.
Refresh tokens sent to a redirect URI registered as
spa expire after 24 hours. Additional refresh tokens acquired using the initial refresh token carry over that expiration time, so apps must be prepared to rerun the authorization code flow using an interactive authentication to get a new refresh token every 24 hours. Users don't have to enter their credentials and usually don't even see any related user experience, just a reload of your application. The browser must visit the log-in page in a top-level frame to show the login session. This is due to privacy features in browsers that block third party cookies.
Refresh token expiration
Refresh tokens can be revoked at any time, because of timeouts and revocations. Your app must handle rejections by the sign-in service gracefully when this occurs. This is done by sending the user to an interactive sign-in prompt to sign in again.
You can't configure the lifetime of a refresh token. You can't reduce or lengthen their lifetime. Configure sign-in frequency in Conditional Access to define the time periods before a user is required to sign in again. Learn more about Configuring authentication session management with Conditional Access.
Not all refresh tokens follow the rules set in the token lifetime policy. Specifically, refresh tokens used in single page apps are always fixed to 24 hours of activity, as if they have a
MaxAgeSessionSingleFactor policy of 24 hours applied to them.
Refresh tokens can be revoked by the server because of a change in credentials, user action, or admin action. Refresh tokens fall into two classes: tokens issued to confidential clients (the rightmost column) and tokens issued to public clients (all other columns).
|Change||Password-based cookie||Password-based token||Non-password-based cookie||Non-password-based token||Confidential client token|
|Password expires||Stays alive||Stays alive||Stays alive||Stays alive||Stays alive|
|Password changed by user||Revoked||Revoked||Stays alive||Stays alive||Stays alive|
|User does SSPR||Revoked||Revoked||Stays alive||Stays alive||Stays alive|
|Admin resets password||Revoked||Revoked||Stays alive||Stays alive||Stays alive|
|User revokes their refresh tokens via PowerShell||Revoked||Revoked||Revoked||Revoked||Revoked|
|Admin revokes all refresh tokens for a user via PowerShell||Revoked||Revoked||Revoked||Revoked||Revoked|
|Single sign-out on web||Revoked||Stays alive||Revoked||Stays alive||Stays alive|
Submit and view feedback for