Azure Active Directory Continuous Access Evaluation

Token expiration and refresh is a standard authentication mechanism and widely used across the industry. When a client application (like Teams) connects to a service (like SharePoint Online), the API requests are authorized using OAuth 2.0 access tokens. By default, those access tokens are valid for one hour, when they expire, the client is redirected back to Azure AD to refresh them. That refresh period provides an opportunity to reevaluate policies for user access. Examples of this are:

 

• User Account is deleted or disabled

• Password for a user is changed or reset

• Multi-factor authentication is enabled for the user

• Administrator explicitly revokes all refresh tokens for a user

• Elevated user risk detected by Azure AD Identity Protection

OAuth

To get a better understanding of continuous access evaluation it is good to know the basic idea behind OAuth. In the traditional client-server authentication model, the client requests an access-restricted resource (protected resource) on the server by authenticating with the server using the resource owner’s credentials. To provide third-party applications access to restricted resources, the resource owner shares its credentials with the third party. This creates several problems and limitations:

 

• Third-party applications are required to store the resource owner’s credentials for future use, typically a password in clear-text.

• Servers are required to support password authentication, despite the security weaknesses inherent in passwords.

• Third-party applications gain overly broad access to the resource owner’s protected resources, leaving resource owners without any ability to restrict duration or access to a limited subset of resources.

• Resource owners cannot revoke access to an individual third party without revoking access to all third parties and must do so by changing the third party’s password.

• Compromise of any third-party application results in the compromise of the end-users password and all of the data protected by that password.

OAuth addresses these issues by introducing an authorization layer and separating the role of the client from that of the resource owner. In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server and is issued a different set of credentials than those of the resource owner. Instead of using the resource owner’s credentials to access protected resources, the client obtains an access token — a string denoting a specific scope, lifetime, and other access attributes. Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource provider. For more information about OAuth 2.0, see the details described in the OAuth 2.0 Authorization Framework, RFC ( Request for Comments) 6749 : https://tools.ietf.org/html/rfc6749

Condition Change

At sometimes the initial conditions change over time compared to the moment when the token was issued (like the user account is disabled). Nowadays the new conditions are only reevaluated when the existing token expires. Up to that moment, the issued user token is respected by the relying partner (like SharePoint Online). So we can say that there is a certain delay in condition change and the effect this has on the party holding the issued token.

Continuous Access Evaluation

Timely response to policy violations or security issues requires a “conversation” between the token issuer (Azure AD) and the relying party (like SharePoint Online). This two-way conversation gives two important capabilities:

 

• The relying party can notice when things have changed, like a client coming from a new location, and tell the token issuer.

• It gives the token issuer a way to tell the relying party to stop respecting tokens for a given user due to account compromise, disablement, or other concerns..

The mechanism for this conversation is continuous access evaluation (CAE). In the most ideal situation, the response to the condition change is near real-time but can be at much as 15 minutes due to the propagation time of events between the involved services. Because CAE requires changes in the communication between the token issuer and resource provider, it can’t be implemented at once. So the initial implementation of CAE focuses on Exchange, Teams, and SharePoint Online.

Token lifetime

Because risk and policy are evaluated in real-time, clients that negotiate continuous access evaluation aware sessions will rely on CAE instead of existing static access token lifetime policies, which means that configurable token lifetime policy will not be honored anymore for CAE-capable clients that negotiate CAE-aware sessions. Token lifetime is increased to be long-lived, up to 28 hours, in CAE sessions. Revocation is driven by critical events and policy evaluation, not just an arbitrary time period. This change increases the stability of applications without affecting security posture. If you are not using CAE-capable clients, your default access token lifetime will remain 1 hour unless you have configured your access token lifetime with the Configurable Token Lifetime (CTL) feature, which I want to discuss in another blog post.

Client and Resource provider support

At the moment of writing only specific client and resource provider combinations are supported. See table below for more details.

	Outlook Web	Outlook Win32	Outlook iOS	Outlook Android	Outlook Mac
SharePoint Online	Supported	Supported	Not Supported	Not Supported	Supported
Exchange Online	Supported	Supported	Supported	Supported	Supported

	Office web apps	Office Win32 apps	Office for iOS	Office for Android	Office for Mac
SharePoint Online	Supported	Supported	Not Supported	Supported	Supported
Exchange Online	Supported	Supported	Not Supported	Supported	Supported

Client-side claim challenge

Before CAE, clients would always try to replay the access token from its cache as long as it was not expired. With CAE, a new case is introduced that a resource provider can reject a token even when it is not expired. To inform clients to bypass their cache even though the cached tokens have not expired, a mechanism called claim challenge is introduced to indicate that the token was rejected and a new access token needs to be issued by Azure AD. CAE requires a client update to understand the claim challenge. The latest version of the following applications below support claim challenge:

 

• Outlook (Windows, iOS, Android, Mac, Web App)

• Teams (Windows, iOS, Android, Mac) (Only for Teams resource)

• Word/Excel/PowerPoint (Windows, iOS, Android, Mac)