Skip to content

Enterprise Mobility + Security


Howdy folks,

I’m excited to announce that we are giving you more control than ever before over core behaviors that directly affect both the security and experience of your users.

We’ve turned on the public preview of the token lifetime configuration in Azure AD!

This is a powerful tool that many of you have been asking for. It makes it possible to dictate the lifetimes of the various tokens issued to your users by Azure AD. With this feature, you will now have more influence over when users are prompted to re-enter their credentials. It’s a great way to configure Azure AD to meet your company’s security and usability goals.

I’ve asked Anchit Nair, the Program Manager for this capability in the Identity Division, to walk you through this exciting new feature.

And as always, we’d love to receive any feedback or suggestions you have!

Best regards,

Alex Simons (Twitter: @Alex_A_Simons)

Director of Program Management

Microsoft Identity Division

——————-

Hi,

I’m Anchit Nair, one of the technical program managers responsible for the Identity Protocols in Azure Active Directory. I’m pleased to announce that ability to configure token lifetimes in Azure AD is going into Public Preview today.

  • This feature will allow you to create token lifetime policies.
  • These policies define how long tokens issued by Azure AD are considered valid.
  • This influences how often users have to enter their credentials.
  • These policies can be set as defaults that apply to all applications in a tenant.
  • Additionally, these policies can be linked to applications or service principals.
  • These policies are managed through PowerShell.

We are opening up this feature for everyone to try during the pubic preview. Please note that some of these capabilities may require an Azure AD Premium subscription once we reach Generally Availability.

Here, you can find the full document as well as a couple of examples and sample code to get you going. However, I did want to highlight a few things:

Scenarios

There are many situations where this feature will be useful. Here are a couple that we hear about the most:

  • When users’ accounts are disabled, they are still able to access applications for a certain period of time. Admins can now reduce the access time by making applications check back in to Azure AD (validating the account’s status) more often.
  • Token lifetime policies can force specific applications to require a user to enter their credentials within a certain period of time (e.g. within 15 minutes). These policies can be used to reduce the risk of users kept signed in to sensitive applications on shared/kiosk devices.

Configurable token lifetimes

To understand what we are now allowing you to do, it is important to understand the basics of tokens issued by Azure AD. It also helps to learn application objects, service principal objects, and the relationship between them.

Until now, each of these tokens had a fixed lifetime that adhered to the Azure AD defaults. This feature allows you to create policies that impact how long a user’s credentials are considered valid.

You can see a summary of the token lifetimes, the defaults and what you can set them to below:

Property Affects Default Minimum Maximum
Access Token Lifetime Access tokens, ID tokens, SAML2 tokens 1 hour 10 minutes 1 day
Refresh Token Max Inactive Time Refresh tokens 14 days 10 minutes 90 days
Single-Factor Refresh Token Max Age Refresh tokens* 90 days 10 minutes Until-revoked**
Multi-Factor Refresh Token Max Age Refresh tokens* 90 days 10 minutes Until-revoked**
Single-Factor Session Token Max Age*** Session tokens (persistent and non-persistent) Until-revoked 10 minutes Until-revoked**
Multi-Factor Session Token Max Age**** Session tokens (persistent and non-persistent Until-revoked 10 minutes Until-revoked**

*This property does not affect refresh tokens used in confidential client flows or refresh tokens issued to federated users that Azure AD has insufficient revocation information for.

**365 days is the maximum explicit length that can be set for these attributes.

***If Single-Factor Session Token Max Age is not set then this value takes the Single-Factor Refresh Token Max Age value. If neither parameter is set, the property takes on the default value (Until-revoked).

****If Multi-Factor Session Token Max Age is not set then this value takes the Multi-Factor Refresh Token Max Age value. If neither parameter is set, the property takes on the default value (Until-revoked).

Priority and Evaluation of Policies

Policies can be linked to applications, service principals or set as the tenant default. You can see how Token Lifetime policy priority is evaluated below:

clip_image002

We understand that a one-size-fits-all approach is not sufficient when it comes to these policies. Less sensitive, “always-on” applications should not be subject to the same security standards as applications that are used to handle highly sensitive, irregular tasks. This is why you can link token lifetime policies to service principals, overriding all other policies and giving admins the ability to create policies specific to the application in their tenant.

However, policies can also be set as the tenant default, affecting all tokens issued for applications within that tenant as long as they are not explicitly overridden by a service principal level policy. This will allow admins to define and set what they expect to be the right behavior for all applications in their tenant. It is important to note that this will affect all applications within the tenant and care must be taken when applying such a policy.

Developers can set a policy on their applications defining the recommended settings for the best experience with their applications. As long as the policy is not overridden by a tenant default or service principal level policy, these are the settings that take effect. It is important that developers are aware that tenants that have different security expectations/requirements may override these settings and that no dependency should be taken on a specific lifetime.

A token’s validity is evaluated at the time it is used. The policy with the highest priority on the application that is being accessed takes effect.

Have fun and keep in touch!

We encourage you to try this new functionality out and explore each of the new dials available to you. It’s important that you let us know what you think and give us any suggestions you may have.

Thanks for your time,

Anchit Nair and the rest of the team here in Azure AD