1

Azure AD Premium has the concept of Conditional Access Policies. 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:

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) Add an Conditional Access Policy in Azure AD premium on the app registration for the app above 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).

Below is the conditional access policy: enter image description here

Below tenant configuration shows that the user cannot select the "Stay signed in?" option when signing into any application in this tenant.

enter image description here

Below the relevant parts of the results of dsregcmd /status. I am aware the SSO status has an effect on Conditional Access Policies.

+----------------------------------------------------------------------+
| Device State                                                         |
+----------------------------------------------------------------------+

             AzureAdJoined : NO
          EnterpriseJoined : NO
              DomainJoined : YES
                DomainName : <redacted>
               Device Name : <redacted>

+----------------------------------------------------------------------+
| User State                                                           |
+----------------------------------------------------------------------+

                    NgcSet : YES
                  NgcKeyId : <redacted>
                  CanReset : NO
           WorkplaceJoined : YES
          WorkAccountCount : 2
             WamDefaultSet : NO

+----------------------------------------------------------------------+
| SSO State                                                            |
+----------------------------------------------------------------------+

                AzureAdPrt : NO
       AzureAdPrtAuthority : NO
             EnterprisePrt : NO
    EnterprisePrtAuthority : NO
k29
  • 641
  • 6
  • 26

1 Answers1

1

I obtained the following response from Microsoft server team and I can confirm that it is accurate, albeit unintuitive:

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.

k29
  • 641
  • 6
  • 26