Azure Active Directory’s Configurable Token Lifetimes

🔊 Listen to Post
As part of authentication, Azure Active Directory (AD) issues different types of tokens, such as:

1. Access Tokens – Default lifetime is one hour
   Used by clients to access resources that are secured by an organization. The Access Tokens cannot be revoked. Therefore, if a hacker gets access to this token, it will be usable until it expires. When the client receives an Access Token, it also receives a Refresh Token. After an hour when the Access Token expires, the client uses the Refresh Token to get a new Refresh Token and an Access Token.
2. SAML Tokens- Default lifetime is one hour
   The SAML 2.0 tokens are used by web-based Software as a Service (SAAS) applications. For example, many enterprise applications that you use in Azure AD for Single Sign-On (SSO) are SAML based.
3. Refresh Tokens
   As described earlier, the client receives Access Token and Refresh Token as a pair. When the Access Token expires, the Refresh Token is responsible for obtaining a new pair of Access/Refresh token. Unlike an Access Token, a Refresh Token can be revoked, but not when it’s being used to refresh an Access Token. The existing Refresh Token is deleted at the time when a new Refresh Token is obtained. Keep in mind that a Refresh Token is constrained to a combination of user and client.
4. ID Tokens
   An ID Token contains a user’s profile information and is used by websites. It too is tied to a combination of user and client. By modifying the lifetime of an ID token, you can control how long a web application’s session should last. This means that you can control how frequently a user needs to be re-authenticated with Azure AD (silently or interactively).
5. SSO Session Tokens – Default lifetime is 24 hours for Non-persistent Session Tokens & 180 days for Persistent Session Tokens
   As part of authentication process, when a user signs-in to Azure AD, an SSO session is created between Azure AD and the user’s web browser. The SSO Token, essentially a cookie, characterizes this session. There are two types of SSO Session Tokens issued by Azure AD, persistent and non-persistent session tokens. Both of these session tokens are stored in the browser as cookies, either as persistent cookies (persistent session token) or non-persistent cookies (non-persistent session token). When a browser is closed, the non-persistent cookies are destroyed so the session is no longer available. The non-persistent session tokens are commonly used. However, if the user selects the Keep me signed in option, then a persistent session token is used. If an SSO Session Token is used before it expires, it is extended automatically for its default lifetime value. Therefore, in case of a Persistent SSO Session Token, its lifetime of 180 days is extended for another 180 days if the token is used within its validity period, and in case of a Non-Persistent SSO Session Token its validity is extended for another 24 hours as long as the token is used before the 24-hour expiration deadline.

The lifetime of a token that’s issued by Azure AD can be configured for all apps within an organization. After the lifetime of a token expires, it needs to be refreshed, or else it can’t be used. The process often takes place silently behind the scenes so the user isn’t aware of what’s going on.

At the time of writing, the configurable token lifetimes were in Preview (i.e. Beta). This simply means that if you were to implement this feature, i.e. modify the lifetime of certain tokens, don’t count on Microsoft providing any tech support because Preview features or products are not usually supported in a production environment.

Token Lifetime Policies

When discussing tokens and their lifetime, it’s important to understand the concept of token lifetime policies. The policies are a set of rules that apply to individual applications  (or all applications) that are used by an organization. You can have multiple policies. One of them can be configured as the default policy. If there are multiple policies with different priorities, the policies are applied in the order of priorities. Policies with higher priority will override the policies with lower priorities. If there are no policies, the default lifetime values are enforced by Azure AD.

NOTE: According to Microsoft, SharePoint Online doesn’t support configurable token lifetime policy. Although you have the ability to create a policy using PowerShell, SharePoint Online will simply ignore the policy.

For more information on policy evaluation and prioritization, visit this page.

Should You Modify the Token Lifetime?

I am hesitant to modify the default values of token lifetimes. As a consulting company, SeattlePro has a policy of not implementing features for our customers that are still in Preview. There are consequences of modifying the lifetime of a token and you shouldn’t modify them just because you can. Make sure you understand and consider the impact of such changes before changing the default timeout value. There is a reason why Microsoft configured the current default settings for the tokens. It may seem like a one hour default for a token lifetime is too short. However, increasing the time poses security risks and can also impact performance.

Configurable Token Lifetime Properties

Microsoft provides the following two tables for the default lifetime value and some exceptions. Use the following tables only as a guideline. Visit Microsoft’s website for up-to-date information and more details.

Exceptions

What to Expect in the Future

After May 1, 2020, which is about 5 months from when I wrote this article, you won’t be able to configure session and refresh tokens using the Configurable Token Lifetime policy. You will, however, be able to configure access token lifetime. Based on customers’ demand, Microsoft will allow us to Configure authentication session management with Conditional Access in Azure AD.

• Go to Azure AD portal (https://portal.azure.com), click on Azure Active Directory link and then do a search for Azure AD conditional access.
• Create a new Conditional Policy.
  
• In the Access controls section, select Session. You will notice a couple of options that are in Preview: Sign-in frequency (Preview) and Persistent browser session (Preview).
  
• You can configure the refresh token lifetimes by configuring the Sign-in frequency in the above screen. Unfortunately, currently the control is rather limited because the gray informational box indicates This control only works with supported apps. Currently, Office 365, Exchange Online, and SharePoint Online are the only cloud apps that support app enforced restrictions. This means that all your third-party apps that you are using with SSO can’t be managed at this time using this particular control.

Visit Configure authentication session management with Conditional Access for more details on how you can configure Conditional Access by customizing the values for sign-in frequency and the persistent browsing sessions.

Copyright © 2019 SeattlePro Enterprises, LLC. All rights reserved.