search

AzureAD / microsoft-authentication-library-for-js

Microsoft Authentication Library (MSAL) for JS
http://aka.ms/aadv2
MIT License
3.64k stars 2.65k forks source link

How does Conditional Access Policy's sign-in frequency affect msals behaviour? #3156

Closed k290 closed 3 years ago

k290 commented 3 years ago

Library

Description

Azure AD Premium has the concept of Conditional Access Policies. As far as I can tell, when you change the sign-in frequency it doesn't affect the access token or refresh token lifetime. Since the access token has a default lifetime of 1 hour, no matter what you set the sign-in frequency to in Azure, after 1 hour the refresh token will be used to fetch a new access token. So setting a sign-in frequency in Azure AD premium has no effect on a default msal app.

And indeed I tested this by doing the following simple steps:

  1. Download the msal angular sample that uses auth code flow with PKCE (https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-angular)
  2. Add an Conditional Access Policy in Azure AD premium on the app registration for the app above
  3. Make sure the policy is applied when the user signs in (e.g. by checking Sign Ins blade or what-if tool on Enterprise app).
  4. Observe no adjustments to access token lifetime or refresh token validity

How is the sign-in frequency supposed to have an effect on an auth code flow msal app's behavior if it doesn't adjust the access token or refresh token lifetime? Is there some additional code I would need to write to make use of the sign-in frequency?

Source

tnorling commented 3 years ago

@k290 Thanks for raising this. This appears to have been an oversight on the server-side. I believe the server folks will address this gap. @hpsin to update status when there's something to share

cc. @nickgmicrosoft We should confirm whether or not this needs to be done in B2C as well

tnorling commented 3 years ago

@k290 After further internal discussion it was determined this should be behaving as designed. Sign-in frequency does not alter token lifetimes but rather when your access token expires and you try to use the refresh token to obtain a new access token the sign-in frequency will be checked and the request will be rejected if you need to reauthenticate.

In other words, once you have an access token, this token is valid for it's lifetime (1 hour). The CA policy will be enforced, if needed, each time you attempt to renew. Can you clarify whether or not you're seeing different behavior?

k290 commented 3 years ago

@tnorling I am seeing different behavior. After 1 hour has passed the request using the refresh token is successful and a new access token is provided to the client.

tnorling commented 3 years ago

@k290 Can you email me a fiddler trace of the initial token acquisition and the unexpected successful renewal? I'll pass it along to our server folks so they can take a look.

k290 commented 3 years ago

@tnorling absolutely. You'll receive the email within the next few days and I'll add another comment here once it is sent.

k290 commented 3 years ago

Hi @tnorling I have sent you an email titled "CAS not taking effect on PKCE MSAL app". It contains the requested fiddler traces as well as additional info that could be useful.

k290 commented 3 years ago

We received the following feedback from the server team with @tnorling's help and I can confirm that it is accurate:

Conditional access executes based on token audiences, and we don’t execute it for id_tokens where the token audience is a public client.

That’s why the CA policy doesn’t kick in

The reason why CA doesn’t execute for id_token for public clients is because CA is meant to protect data from the cloud, and having an id_token from a public client doesn’t grant access to any data from the cloud.

It’s about the data that could be accessed in their request.

They can try few other options:

They can change their policy to apply to “All apps”, then SIF (Sign In Frequency) will kick in. E.g. They can try to set the policy on Exchange Online, and request mail.read scope Another example: They can try to set the policy for Sharepoint Online, and request files.read scope

So, we will apply the conditional access policy if the conditions are met, but only for tokens that could access data in the cloud.

I changed the conditional access policy to apply to "all apps" instead of just the app registration for the msal app. The MSAL app does correctly reject the refresh token and redirect after 1 hour. I did not try the other examples, but they also seem like valid workarounds given what would trigger the SIF to kick in.