Azure AD CA Authentication Context, a look a tokens

Azure AD Conditional Access has been quite powerful for a long time, but just got way better with the new authentication context feature. Authentication context is essentially a new way to scope conditional access policies, where instead of targeting an application, you target a context, such as “High security operations” or “Operations requiring consenting to terms of use”. Using the authentication context, you can split your applications into several assurance levels, each being targeted by a separate set of CA policies.

Let’s have a look at the tech first, with tokens and stuff.

I have many posts about how to get tokens for applications using different types of grants etc., and in this example we will use an implicit flow for simplicity. With implicit flow, we will essentially request a token directly from the authorization endpoint, that will be provided to use in the url, available client side only, but that is good enough for demo purposes.

Let’s start by creating an application:

Second, enable a redirect to https://jwt.ms and enable implicit grant with ID token:

After adding the url, we can now go to the following url in order to sign in:

https://login.microsoftonline.com/TENANTID/oauth2/v2.0/authorize?client_id=APPLICAITONID&response_type=id_token&redirect_uri=https://jwt.ms&state=12345&scope=openid&nonce=12345

We have now been able to issue a token, but there is no “acrs” claim available, meaning we have no authentication context.

Now we are ready to create authentication contexts. In this example, we will create two new contexts – “High security operation” and “GDPR consent”.

After creating the authentication contexts, you’ll see that they all get an ID on the format “cX”, where X is an incrementing number. We will refer to these later.

Next, after creating the authentication contexts, we are ready to add CA policies that targets them. Create a new CA policy targeting all users:

I have also added a CA policies requiring accepting my “GDPR consent” terms of use, targeting the “GDPR consent” authentication context:

Now, let’s open a new browser window and sign into the app with the first url:

https://login.microsoftonline.com/54c9fb19-e0ab-4217-98a5-7fc04b0da9d8/oauth2/v2.0/authorize?client_id=8b130b5a-f06b-4126-8c71-bd5ae868c7af&response_type=id_token&redirect_uri=https://jwt.ms&state=12345&scope=openid&nonce=12345

I am signed in with a single factor:

And we can see no “acrs” claim:

Now, in order to “elevate” to the c1 authentication context (High security operation), we must add a “claims” parameter, which is a url encoded json document, for requesting attributes:

https://login.microsoftonline.com/54c9fb19-e0ab-4217-98a5-7fc04b0da9d8/oauth2/v2.0/authorize?client_id=8b130b5a-f06b-4126-8c71-bd5ae868c7af&response_type=id_token&redirect_uri=https://jwt.ms&state=12345&scope=openid&nonce=12345&claims=%7B%22id_token%22%3A%7B%22acrs%22%3A%7B%22essential%22%3Atrue%2C%22value%22%3A%22c1%22%7D%7D%7D

Suddenly I must authenticate with MFA!:

And now we can actually see that the acrs claim has been populated with “c1”, our “High security operation” authentication context:

Next, let’s try c2:

https://login.microsoftonline.com/54c9fb19-e0ab-4217-98a5-7fc04b0da9d8/oauth2/v2.0/authorize?client_id=8b130b5a-f06b-4126-8c71-bd5ae868c7af&response_type=id_token&redirect_uri=https://jwt.ms&state=12345&scope=openid&nonce=12345&claims=%7B%22id_token%22%3A%7B%22acrs%22%3A%7B%22essential%22%3Atrue%2C%22value%22%3A%22c2%22%7D%7D%7D

And suddenly, we are asked to consent to the GDPR policy document:

And now the value if acrs is c2, with c1 forgotten about:

You can of course also ask for both c1 and c2 like this:

https://login.microsoftonline.com/54c9fb19-e0ab-4217-98a5-7fc04b0da9d8/oauth2/v2.0/authorize?client_id=8b130b5a-f06b-4126-8c71-bd5ae868c7af&response_type=id_token&redirect_uri=https://jwt.ms&state=12345&scope=openid&nonce=12345&claims=%7B%22id_token%22%3A%7B%22acrs%22%3A%7B%22essential%22%3Atrue%2C%22values%22%3A%5B%22c2%22%2C%22c1%22%5D%7D%7D%7D

So, Microsoft has provided extensive developer documentation on how to use this feature, and the acrs claim must be consumed by the apps, with conditions checking for values being present, redirecting the url to “get your acrs straight”. I will dive more into this in a later blog post.