Few days ago, the Azure AD team announced that they are changing the default values for some of the parameters controlling token lifetimes. In a nutshell, any newly created tenants will have refresh token inactivity period of 90 days and unlimited max age for any refresh tokens. You can find the full article here.
Now, generally speaking, this is a good thing. Having seamless sign-on experience is what the users expect, and the fewer authentication prompts they get the better. However, in some cases, such as when a user leaves the company, this might have some unwanted consequences. It’s not that uncommon to see complaints and queries from Office 365 administrators about people still being able to access resources or sent mail after they account being disabled. The causes for such behavior are multi-layered, and not specific to Azure AD or the cloud. Experienced admins are already aware that there is a lot of caching going on front- and back-end servers. Replication can be a factor too, as changes might take some time to propagate through the whole environment. And in the case of Modern authentication, the access and refresh token model also has some implications.
First of all, if the user has a valid access token, he will continue to be able to access the service for up to an hour. Yes, we can now customize the access token values as well, so we do have options (read here). The default setting of 1h for the validity of Access tokens means that if you want to immediately revoke access, you have to perform additional operations, such as disabling mailbox protocols for the case of Exchange (read here). The newly introduced defaults change nothing in this regard!
Next, it’s worth mentioning that the new defaults are not paired with any new token revocation triggers. To remind you, those include:
- Manual revocation via the Revoke-AzureADUserAllRefreshToken cmdlet (requires the AzureAD PowerShell module) or by setting the StsRefreshTokensValidFrom parameter value via Set-MsolUser
- Conditional access policies
- Password changes or password expiration
- For any synchronized users, the LastPasswordChangeTimestamp attribute. If this attribute is not being synced, a shorter value for the refresh token lifetime is configured (read the note here)
- Some additional triggers for federated accounts (changes in account state, changes in device state)
As the changes affect only newly created tenants, they should not impact any organization that is already using Office 365 or any organization that has configured custom token lifetimes. And, one can always use the AzureAD PowerShell module to change those settings. For example, this is how to configure a policy with the “older” defaults:
New-AzureADPolicy -Definition @('{"TokenLifetimePolicy":{"Version":1,"MaxInactiveTime":"14.00:00:00″,"MaxAgeSingleFactor":"90.00:00:00″,"MaxAgeMultiFactor":"90.00:00:00″,"MaxAgeSessionSingleFactor":"until-revoked","MaxAgeSessionMultiFactor":"until-revoked"}}') -DisplayName "OrganizationDefaultPolicyScenario" -IsOrganizationDefault $true -Type "TokenLifetimePolicy"