The Azure Active Directory identity platform authenticates users and provides security tokens, such as access token, refresh token, and ID token. The access token allows a client application to access Microsoft Graph APIs and other protected resources. The access tokens are valid for only a short period, so we need to use the refresh token to get the new access token.
In this post, we will learn about the lifetime of refresh tokens and the reasons for the token expiration, also explore different ways to revoke the user refresh tokens.
Access Token lifetime: Access tokens are short-lived; it contains information about the user and the resource for which the token is intended. The token may expire in 1 hour time, for the exact expiration time, check the value of expires_on attribute that is returned when acquiring the token.
Refresh Token lifetime: Refresh tokens are long-lived; can be used to renew an expired access token to retain access to resources for an extended period. The lifetime of refresh tokens is relatively long for web apps and native apps (ex: 90 days). However, for single-page apps (spa), the refresh token will expire after 24 hours.
Summary
- Refresh Token Expiration
- Revoke Refresh Token using PowerShell
- Revoke Refresh Token using Microsoft Graph API
- Revoke Sessions from Azure AD Portal
- Revoke Sessions through Conditional Access policy
Refresh Token Expiration
The default lifetime for the refresh token is 90 days. However, in some cases, refresh tokens expire, or revoked, or lack sufficient privileges for the desired action. In this case, the application needs to expect and handle errors returned by the token issuance endpoint correctly.
You will get the following error (invalid_grant – AADSTS50173) when you try to get a new access token using the expired refresh token.
{“error”:”invalid_grant”,”error_description”:”AADSTS50173: The provided grant has expired due to it being revoked, a fresh auth token is needed. The user might have changed or reset their password. The grant was issued on ‘2021-11-23T12:15:52.1109695Z’ and the TokensValidFrom date (before which tokens are not valid) for this user is ‘2021-11-23T13:30:39.0000000Z’}
The refresh token can be expired due to either if the password is changed/reset for the user or the token has been revoked either by the user or admin through PowerShell or from the Azure portal. For more information, see Refresh Token Expiration to know the possible reasons for the revocation of the refresh token.
Revoke Refresh Token using PowerShell
We can use the Revoke-AzureADUserAllRefreshToken cmdlet to invalidate the refresh tokens issued to all the applications for a user by resetting the signInSessionsValidFromDateTime user property to the current date-time.
$User = Get-AzureADUser -SearchString '[email protected]'
Revoke-AzureADUserAllRefreshToken -ObjectId $User.ObjectID
Revoke Refresh Token using Microsoft Graph API
You can revoke user sign-in sessions by using the Revoke sign-in session API.
POST https://graph.microsoft.com/v1.0/{id | userPrincipalName}/revokeSignInSessions
Revoke Sessions from Azure AD Portal
Go to Azure portal, navigate to Azure Active Directory blade > Users > All Users, select (double-click) the required user and click the Revoke Sessions button on top of the toolbar.
Revoke Sessions through Conditional Access policy
Apart from the listed reasons in the above post, the tokens can also be controlled through Sign-in frequency control in the Conditional Access policy. Sign-in frequency provides another way to control the refresh token.
The default Azure AD configuration for user sign-in frequency is 90 days. You can create a new conditional access policy, define Sign-in frequency under Session controls, and set the required time interval (ex: 5 days or 12 hours) to force the user to sign in again. For more information, see Control user authentication session with Conditional Access.
You can also have a look at Continuous access evaluation (CAE) to know more about how the critical events are evaluated and how users lose access to organizational resources (ex: SharePoint Online files, email, and Teams) from Microsoft 365 client apps within minutes after a critical event.