Changes to the Token Lifetime Defaults in Azure AD

[Alex Simons (AZURE)]

First published on CloudBlogs on Aug, 31 2017
Howdy folks, I'm happy to share that as part of our efforts to eliminate unnecessary signin prompts while maintaining high levels of security, we're making some major improvements to how we manage refresh tokens lifetimes. This blog post goes into much greater technical detail than we usually discuss in this blog. But this is an important topic for many of you, so I think it's warranted.

• Refresh Token Inactivity: 90 Days
• Single/Multi factor Refresh Token Max Age: until-revoked
• Refresh token Max Age for Confidential Clients: until-revoked

It's important to note that these new defaults will not apply to your tenant if you have customized these settings. Additionally if you want to override these settings with your own custom setting, you can do that.

Why now?

We are keenly aware that unwanted authentication prompts degrade the user experience, result in user frustration, and often lead to so-called "shadow IT" where users end-run enterprise IT and use personally acquired SaaS apps to get their jobs done. As part of this effort to remove user friction, we analyzed the impact of our current default Refresh Token lifetime and found that nearly 20% of authentication prompts were caused by refresh token expiration. We also analyzed account compromise to see if there is correlation between refresh token lifetime and the likelihood of account compromise. We were pleased to find there was no statistically significant correlation between token lifetimes and compromised accounts. Using this and other data on usage patterns, we determined that extending refresh token lifetime will greatly improve the authentication experience while still maintaining high security standards.

What do these lifetimes control?

To understand the lifetimes and the changes we've made, it's important to understand the basics of tokens issued by Azure AD . Although the refresh tokens now last longer, access tokens still expire on much shorter time frames. When the access token a client app is using to access a service or server expires, the client must request a new access token by sending the refresh token to Azure AD. As part of that request, Azure AD uses our conditional access system and identity protection system to assure the user and their device are in a secure and compliant state before issuing a new access token. Refresh tokens are also tied to the user credential originally provided by the user. This means that if a password was used to issue a refresh token, the refresh token and any additional refresh tokens derived from it are tied to that password. If the password is changed or expires, all derived refresh tokens become invalid and the user would be forced re-authenticate. Additionally, when a client gets an access token to access a protected resource, the client receives both a refresh token and a new access token. This allows Azure AD to constantly renewal of refresh tokens on a device that's actively being used. On the other hand, if a user has not been active on her device for a certain period, her refresh token will become stale. Refresh token inactivity This policy controls how old a refresh token can be before it expires and can no longer be used to retrieve a new access/refresh token pair when attempting to access a resource. It forces users who haven't been active on their client to re-authenticate to retrieve a new refresh token. This change won't apply to your tenant if you configured Refresh Token Max Inactive Time to a custom value. Single/multi-factor refresh token MaxAge This policy controls how long a user can use a refresh token to get a new access/refresh token pair after they last successfully provided their credentials. After a user authenticates and receives a new refresh token, the refresh token can be used to obtain new access/refresh token pairs for the specified period called Refresh Token MaxAge. This is true if the current refresh token is not revoked or left unused for longer than the inactive time. (See above for Refresh Token Inactivity period). After Refresh Token MaxAge expires, the user must reauthenticate to receive a new refresh token, even if they've been actively refreshing the token. Refresh token MaxAge for confidential clients This policy controls how long a confidential client can use a refresh token to get a new access/refresh token pair after they last actively provided consent to access specific resources. After the client authenticates and receives a new refresh token, it can use the refresh token flow for the specified period. This is true if the current refresh token isn't revoked, and isn't left unused for longer than the inactive time. (See above for Refresh Token Inactivity period). After this period, the user must consent to the confidential client again for the client to continue receiving a new refresh token, even if they have been actively refreshing the token. Please note that MaxAge for confidential clients can't be modified; it can, however, be revoked if needed, by using the steps in the How can I revoke refresh tokens? section below.

Can I change/revert these settings?

You can use the configurable token lifetimes feature to control these lifetimes. To specifically revert the lifetimes in your tenant to their previous values, follow the guidelines below. Set defaults in tenant to older values If you are new to Azure AD, we recommend you learn how to get an Azure AD tenant before you proceed. To get started:

1. Download the latest Azure AD PowerShell Module Public Preview release .
2. Run the Connect command to sign in to your Azure AD admin account. Run this command each time you start a new session:
   Connect-AzureAD -Confirm
3. To create the policy, run the following command:
   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"

How can I revoke refresh tokens?

Revoking a user's active refresh tokens is simple and can be done on an ad-hoc basis. You do this by setting the StsRefreshTokensValidFrom on the user object, so any refresh tokens tied to a credential provided before the time this attribute was set will no longer be honored by Azure AD. The user will be forced to re-authenticate to receive a new refresh token. Follow these steps to revoke a user's refresh tokens:

1. Download the latest Azure AD PowerShell V1 release .
2. Run the Connect command to sign in to your Azure AD admin account. Run this command each time you start a new session:
   Connect-msolservice
3. Set the StsRefreshTokensValidFrom parameter using the following command:
   Set-MsolUser -UserPrincipalName <UPN of the User> -StsRefreshTokensValidFrom ("<current date>")

Let us know what you think!

Once you've had a chance to experience these changes, let us know what you think! As always, we'd love to hear any feedback or suggestions you have. Best regards, Alex Simons (Twitter: @Alex_A_Simons ) Director of Program Management Microsoft Identity Division   [Updated 9/5/2017, 10:52 am Pacific to clarify that customers who have customized these settings or are using federation that these changes will not impact them] [Updated 10/3/2017 to clarify that this change will not effect customers who have customized these settings will not be impacted, but those using federation who have not changed these settings will be effected.]