Edit

Conditional Access: Authentication flows (Preview)

  • Article

Microsoft Entra ID supports a wide variety of authentication and authorization flows to provide a seamless experience across all application and device types. Some of these authentication flows, are higher risk than others. To provide more control over your security posture, we’re adding the ability to control certain authentication flows to Conditional Access. This control starts with the ability to explicitly target device code flow.

Device code flow

Device code flow is used when signing into devices that might lack local input devices like shared devices or digital signage. Device code flow is a high-risk authentication flow that might be used as part of a phishing attack or to access corporate resources on unmanaged devices. You can configure the device code flow control along with other controls in your Conditional Access policies. For example, if device code flow is used for android based conference room devices, you might choose to block device code flow everywhere except for android devices in a specific network location.

You should only allow device code flow where necessary. Microsoft recommends blocking device code flow wherever possible.

Authentication transfer

Authentication transfer is a new flow that offers a seamless way to transfer authenticated state from one device to another. For example, users could be presented with a QR code within the desktop version of Outlook that, when scanned on their mobile device, transfers their authenticated state to the mobile device. This capability provides a simple and intuitive user experience that reduces the overall friction level for users.

The ability to control authentication transfer is in preview use the Authentication flows condition in Conditional Access to manage the feature.

Protocol tracking

To ensure Conditional Access policies are accurately enforced on specified authentication flows, we use functionality called protocol tracking. This tracking is applied to the session using device code flow or authentication transfer. In these cases, the sessions are considered protocol tracked. Any protocol tracked sessions are subject to policy enforcement if a policy exists. Protocol tracking state is sustained through subsequent refreshes. Nondevice code flow or authentication transfer flows can be subject to enforcement of authentication flows policies if the session is protocol tracked.

For example:

  1. You configure a policy to block device code flow everywhere except for SharePoint.
  2. You use device code flow to sign-in to SharePoint, as allowed by the configured policy. At this point, the session is considered protocol tracked
  3. You try to sign in to Exchange within the context of the same session using any authentication flow not just device code flow.
  4. You're blocked by the configured policy due to the protocol tracked state of the session

Sign-in logs

When configuring a policy to restrict or block device code flow, it’s important to understand if and how device code flow is used in your organization. Creating a Conditional Access policy in report-only mode or filtering the sign-in logs for device code flow events with the authentication protocol filter can help.

To aid in troubleshooting protocol tracking related errors, we’ve added a new property called original transfer method to the activity details section of the Conditional Access sign-in logs. This property displays the protocol tracking state of the request in question. For example, for a session in which device code flow was performed previously the original transfer method is set to Device code flow.

Troubleshooting unexpected blocks

If you have a sign-in unexpectedly blocked by a Conditional Access policy, you should confirm whether the policy was an authentication flows policy. You can do this confirmation by going to sign-in logs, clicking on the blocked sign-in, and then navigating to the Conditional Access tab in the Activity details: sign-ins pane. If the policy enforced was an authentication flows policy, select the policy to determine which authentication flow was matched.

If device code flow was matched but device code flow wasn't the flow performed for that sign-in, that means the refresh token was protocol tracked. You can verify this case by clicking on the blocked sign-in and searching for the Original transfer method property in the Basic info portion of the Activity details: sign-ins pane.

Note

Blocks due to protocol tracked sessions are expected behavior for this policy. There is no recommended remediation.

Related content