Recommendations for conditional access and multi-factor authentication in Microsoft Flow

Conditional Access is a feature of Azure Active Directory (Azure AD) that lets you control how and when users can access applications and services. Despite its usefulness, you should be aware that using conditional access may have an adverse or unexpected effect on users in your organization who use Microsoft Flow to connect to Microsoft services that are relevant to conditional access policies.

Conditional access policies are managed through the Azure portal and may have several requirements, including (but not limited to) the following:

• Users must sign in by using multi-factor authentication (MFA) (typically password plus biometric or other device) to access some or all cloud services.
• Users may access some or all cloud services only from their corporate network and not from their home networks.
• Users may use only approved devices or client applications to access some or all cloud services.

The following screenshot shows an MFA policy example that requires MFA for specific users when they access the Azure management portal.

You can also open the MFA configuration from the Azure portal. To do this, select Azure Active Directory > Users and groups > All users > Multi-Factor Authentication, and then configure policies by using the service settings tab.

MFA can also be configured from Microsoft 365 admin center. A subset of Azure MFA capabilities is available to Office 365 subscribers. For more information about how to enable MFA, see Set up multi-factor authentication for Office 365 users. 

The remember multi-factor authentication setting can help you to reduce the number of user logons by using a persistent cookie. This policy controls the Azure AD settings that are documented in Remember Multi-Factor Authentication for trusted devices.

Unfortunately, this setting changes the token policy settings that make the Flow connections expire every 14 days. This is one of the common reasons why Flow connections fail more frequently after MFA is enabled. We recommend that you do not use this setting. Instead, you can achieve the same functionality by using the following token lifetime policy.

Recommended token lifetime settings after MFA is enabled

The primary adverse effect of conditional access on Flow is caused by the settings in the following table. The table shows the default values for the token lifetime settings. We recommend that you do not change these values.

Setting	Recommended value	Effect on Flow
MaxInactiveTime	90 days	If any Flow connection is idle (unused by Flow runs) for longer than this timespan, any new Flow run after the expiry time fails and returns the following error: AADSTS70008: The refresh token has expired due to inactivity. The token was issued on Time and was inactive for 90.00:00:00
MaxAgeMultiFactor	Until-Revoked	This setting controls how long multi-factor refresh tokens (the kind of tokens that are used in Flow connections) are valid. The default setting means that there is effectively no limit on how long a Flow connection can be used – unless a tenant admin specifically revokes the user's access. Setting this value to any fixed timespan means that after that duration (regardless of use or inactivity), a Flow connection becomes invalid and the Flow runs then fail. When this occurs, the following error message is generated. This error requires users to repair or re-create the connection: AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access…
MaxAgeSingleFactor	Until-Revoked	This setting is same as the MaxAgeMultiFactor setting, but for single-factor refresh tokens.
MaxAgeSessionMultiFactor	Until-Revoked	There is no direct effect on Flow connections. This setting defines the expiration of a user session for web apps. This setting can be changed by the admins depending on how frequently they want the users to sign in to web apps before the user session expires.

Some settings that are configured as part of enabling multi-factor may affect the Flow connection. When MFA is enabled from Microsoft 365 admin center and the remember multi-factor authentication setting is selected, the configured value overrides the default token policy settings, MaxAgeMultiFactor and MaxAgeSessionMultiFactor. Flow connections start failing when MaxAgeMultiFactor expires, and it requires the user to use an explicit logon to fix the connections.

We recommend that you use the token policy instead of the remember multi-factor authentication setting to configure different values for the MaxAgeMultiFactor and MaxAgeSessionMultiFactor settings. The token policy lets Flow connections keep working while also controlling a user logon session for the Office 365 web apps. MaxAgeMultiFactor has to have a reasonably longer period - ideally, the Until-Revoked value. This is to make Flow connections keep working until the refresh token is revoked by the admin. MaxAgeSessionMultiFactor affects a user logon session. Tenant administrators can select the value that they want, depending on how frequently they want the users to sign in to the Office 365 web apps before the session expires.

To view Active Directory policies in your organization, you can use the following commands. The Configurable token lifetimes in Azure Active Directory (Preview) document provides specific instructions to query and update the settings in your organization.

View existing token lifetime policies

Install-Module AzureADPreview

PS C:\WINDOWS\system32> Connect-AzureAD

PS C:\WINDOWS\system32> Get-AzureADPolicy

Run the commands in the next sections to create a policy or change an existing policy in the following scenarios:

• The remember multi-factor authentication setting is enabled from Microsoft 365 admin center.
• An existing token lifetime policy is configured by using a short expiration value for the MaxAgeMultiFactor setting.
   

Create a new token lifetime policy

PS C:\WINDOWS\system32>  New-AzureADPolicy -Definition @('{"TokenLifetimePolicy":{"Version":1,"MaxAgeMultiFactor":"until-revoked","MaxAgeSessionMultiFactor":"14.00:00:00"}}') -DisplayName "DefaultPolicyScenario" -IsOrganizationDefault $true -Type "TokenLifetimePolicy"

Change an existing token lifetime policy

If a default organization policy already exists, update and override the settings by following these steps:

1. Run the following command to find the policy ID that has the IsOrganizationalDefault attribute set to True:
    

   get-azureadpolicy

    
2. Run the following command to update the token policy settings:
    

   PS > Set-AzureADPolicy -Id  <PoliycId> -DisplayName "<PolicyName>" -Definition @('{"TokenLifetimePolicy":{"Version":1,"MaxAgeMultiFactor":"until-revoked","MaxAgeSessionMultiFactor":"14.00:00:00"}}}}')

   
   Note Any additional settings that are configured in the original policy have to be copied to this command.

After you configure the policy, tenant admins can clear the remember multi-factor authentication check box because the expiration of a user session is configured by using the token lifetime policy. The token lifetime policy settings make sure that Flow connections continue to work in the following conditions:

• Office 365 web apps are configured to expire the user session after X days (14 days in example in step 2).
• The apps ask users to log on again by using MFA.

Effects on the Flow portal and embedded experiences

This section details some of the adverse effects that conditional access can have on users in your organization who use Flow to connect to Microsoft services relevant to a policy.
 

Effect 1: Failure on future runs

If you enable a conditional access policy after flows and connections are created, flows fail on future runs. Owners of the connections will see the following error message in the Flow portal when they investigate the failed runs:

When users view connections on the Flow portal, they see an error message that resembles the following:

To resolve this issue, users must sign in to the Flow portal under conditions that match the access policy of the service that they are trying to access (such as multi-factor, corporate network, and so on), and then repair or re-create the connection.
 

Effect 2: Automatic connection creation failure

If users don't sign in to Flow by using criteria that matches the policies, the automatic connection creation to first-party Microsoft services that are controlled by the conditional access policies fail. Users must manually create and authenticate the connections by using criteria that matches the conditional access policy of the service that they try to access. This behavior also applies to 1-click templates that are created from the Flow portal.

To resolve this issue, users must sign in to the Flow portal under conditions that match the access policy of the service they try to access (such as multi-factor, corporate network, and so on) before they create a template.
 

Effect 3: Users can't create a connection directly

If users don't sign in to Flow by using criteria that matches the policies, they can't create a connection directly, either through PowerApps or Flow. Users see the following error message when they try to create a connection:

To resolve this issue, users must sign in under conditions that match the access policy of the service that they are trying to access, and then re-create the connection.
 

Effect 4: People and email pickers on the Flow portal fail

If Exchange Online or SharePoint access is controlled by a conditional access policy, and if users don't sign in to Flow under the same policy, people and email pickers on the Flow portal fail. Users can't get complete results for groups in their organization when they perform the following queries (Office 365 groups will not be returned for these queries):

• Trying to share ownership or run-only permissions to a flow
• Selecting email addresses when building a flow in the designer
• Selecting people in the Flow Run panel when selecting inputs to a flow

Effect 5: Using flow features embedded in other Microsoft services

When a flow is embedded in Microsoft services such as SharePoint, PowerApps, Excel, and Teams, the flow users are also subject to conditional access and multi-factor policies based on how they authenticated to the host service. For example, if a user signs in to SharePoint by using single-factor authentication, but tries to create or use a flow that requires multi-factor access to Microsoft Graph, the user receives an error message.
 

Effect 6: Sharing flows by using SharePoint lists and libraries

When you try to share ownership or run-only permissions by using SharePoint lists and libraries, Flow cannot provide the display name of the lists. Instead, it displays the unique identifier of a list. The owner and run-only tiles on the Flow properties page for already-shared flows will be able to display the identifier, not the display name.

More importantly, users may also be unable to discover or run their flows from SharePoint. This is because, currently, the conditional access policy information is not passed between Power Automate and SharePoint to enable SharePoint to make an access decision.

 

Effect 7: Creation of SharePoint out-of-box flows

Related to Effect 6, the creation and execution of SharePoint out-of-box flows, such as the "Request Signoff" and "Page Approval" flows, can be blocked by conditional access policies. SharePoint documentation on conditional access policies indicates that these policies can cause access issues that affect both first-party and third-party apps. 

This scenario applies both to the network location and to conditional access policies (such as "Disallow Unmanaged Devices"). Support for the creation of SharePoint out-of-box flows is currently in development. We will post more information in this article when this support becomes available.

In the interim, we advise users to create similar flows themselves, and manually share these flows with the desired users, or to disable conditional access policies if this functionality is required.