Conditional Access authentication context now in public preview

Published May 26 2021 11:00 AM 38.2K Views

Howdy folks,                                                                                                                                                                    

Today we are starting the Conditional Access authentication context public preview. Authentication context allows apps to trigger policy enforcement when a user accesses sensitive data or actions, keeping users more productive and your sensitive resources secure.


We have added this capability for more granular policy targeting because of your feedback – let us know what you think!


Caleb Baker, from our PM team, will walk you through the details below.




Alex Simons





Getting started with Conditional Access authentication context

Hey there, I am Caleb from the Azure AD team.


We've heard from many of you that you want to trigger a Conditional Access policy when sensitive content in your apps is accessed. This includes requiring multi-factor authentication, a compliant device or even GPS-based location. Existing app-level Conditional Access policies don't support this level of resource granularity, so we've added support for authentication contexts.


Now that Conditional Access authentication context is in public preview it’s great to be able to go deeper into some of the details. I can’t wait to see how people use it and integrate authentication context into their own apps.


You can modify your line of business apps, or, thanks to integration with Microsoft Cloud App Security (MCAS), Microsoft Information Protection (MIP), and SharePoint Online, use it with all kinds of cloud apps right away!


Let’s get started!

When you use authentication context, first you will create a custom authentication context value. This is how apps will trigger Conditional Access policies when sensitive data or actions are accessed.


You can do this from the new Conditional Access authentication context tab, and clicking New authentication context.


AuthContext (Preview).png


You’ll then provide a display name and description for the new authentication context. We recommend using a name that captures the authentication requirements. For example, Controls trusted devices or Contoso strong auth.


Modify authentication context.png


After creating a new authentication context, you then attach it to Conditional Access policies. These are the policies that will be enforced when an application triggers the authentication context. You author these policies in the Conditional Access policy admin UX, the same as any other Conditional Access policy. The only difference is that instead of assigning policy to a cloud app you’ll assign it to an authentication context.




Now that you’ve created an authentication context apps can make use of it. I’ll show an example with MCAS session policy, this will enforce policy when a user downloads a file from an app. MIP label management in the Office Security and Compliance Center has a similar experience for applying authentication context values.




Now when a user attempts to download a sensitive file from an app that is configured to use the MCAS session policy, they will need to satisfy the attached Conditional Access policy.

Here are some of the ways customers have been using authentication context with MCAS and SharePoint.

  • Requiring users to authenticate with multi-factor authentication (MFA) when they download sensitive files from any SaaS app on the web, like Office 365, Salesforce, Workday, and more.
  • Require terms of use for SharePoint site collections that have been classified as confidential. For several customers this allows them to move sensitive documents to secured sites in SharePoint online, and complete their migration from on-premises.


These documents will help you to learn more about configuring these policies.


Adding authentication context into your apps

Any app using OpenID Connect/OAuth 2.0 for authentication can also use authentication context values, including apps developed by your organization. This allows your apps to better protect sensitive resources, like high-value transactions or viewing employee personal data.

We’ve built this support on a standards-based pattern, commonly used by apps prompting for multi-factor authentication, to help simplify app integration. Of course, you can also use the Microsoft Authentication Library (MSAL) to further simplify app development.


Apps can trigger a specific authentication context value by using an OpenID Connect claim challenge, to request a specific authentication context claim value.


Context Value.png


Once the user has been challenged and satisfied policy, they will be issued a new sign-in token containing the required authentication context claim. The app can then use the presence of the claim to grant access.


Here are some additional resources to help with app development, using authentication context.


Next, we’ll be working toward GA and adding support for even more integrations, like Privileged Identity Management role activation!


As always, we’d love to hear from you. Please let us know what you think in the comments below or on the Azure AD feedback forum.




Caleb Baker



Learn more about Microsoft identity:


Occasional Contributor

This is great.  We are currently working to implement Workday.  Workday already has a similar capability for users with elevated rights when using the Workday native sign-in.  Currently for our AAD auth for Workday we are applying session policies to those users based on group membership.  It would be great to see Microsoft and Workday provide this capability to provide the contextual conditional access controls without having to rely on elevated users being added to a specific group.

Regular Contributor

It would be cool to see this function to wrap some of the settings of O365 apps. For example, Auto-Forwarding settings in Outlook. Require MFA to to confirm the person is doing the change when they need to forward emails to another address.


Maybe this is possible and I just haven't read the documentation yet...

Senior Member

@Tim It isn't possible with the public preview, but think it's a great suggestion.

Senior Member

Could this be used to trigger MFA when our users access an application in another tenant as a B2B account?

Occasional Visitor

@caleb_b  - the announcement post at says that authentication context can be used with PIM. Does the public preview include the PIM integration? Is there any documentation on how to use it?

Senior Member

@fuscob support in PIM is still coming, but some final work is being done before the PIM preview.

Senior Member

@apnet1205 , this policy would be used by the resource tenant. So a resource tenant admin could use it to require MFA for guests. Auth context won't help enforce MFA for your users accessing other tenants - however there is some feature work happening in Conditional Access to enable that case.

Senior Member

@caleb_b That's great thanks - any rough expectation on when that feature would appear?

Senior Member

Great feature! Any plans to also support SAML apps?

Frequent Visitor

That's really a great feature for more granular access control. But would like to clarify about the license side. I saw the document mentioned that M365 E5 or E5 compliance is required, so for example if I configure an authentication context and assign the label to a sharepoint site and configure conditional access policy based on authentication context, then each users (including internal and guest) access this website need to have M365 E5 or E5 compliance license? If the user don't have the required license, access is expected to be blocked or the conditional access policy will be bypassed then those users will get access to the sharepoint site? Thanks.

Occasional Contributor

@terulei when I asked about Guest access licensing in the past I was told that you can't license people outside your org.  That's where the Guest entitlements come in.  I believe for every 1 E5 user internal, you can have 5 external/guest users leveraging the functionality.  Note that if you give a user an ID in your tenant vs. inviting them as a guest, then they would be considered an internal user and would have to be licensed as an internal user. 


I haven't looked specifically at the license requirements for this functionality yet, so I'll leave that answer to someone else.  But generally, with MS licensing, if a user benefits from a feature, they must be licensed for the feature.  So if a SharePoint site has a CA policy with Authentication Context assigned to it, anyone who accesses that site and has the policy evaluated against them, would need to be licensed for the feature.

Frequent Visitor

@Greg_C_Gilbert Thanks a lot for your information and it's very useful. I have customer with E5 for their information workers and F1 for frontline workers, so the feature become useless unless purchasing compliance add-on (and not sure if F5 compliance add on can cover since from document in website only E5 is mentioned to include the feature). Hope there will be someone also familiar of license part to share more information.

Version history
Last update:
‎Aug 19 2021 04:23 PM
Updated by: