Microsoft Outlook for the web: Third-party cookie block causes users to sign in again on Chrome and Edge

Updated October 9, 2024: We have updated the rollout timeline below. Thank you for your patience.

As communicated in MC711020 Outlook: Outlook for web – new application ID (January 2024), Microsoft Outlook for the web is undergoing an authentication platform migration to a public client authentication model using MSAL (Microsoft Authentication Library). The change to client-side authentication will be subject to Google's third-party cookie block that may be active in Chrome and Edge.

Google's third-party cookie block impacts navigation to Microsoft Entra ID to perform silent single sign-on (SSO). To overcome this block, Outlook for the web will present a banner for the user to refresh their session. This will enable navigation to Entra ID to refresh their token. SSO-enabled Windows devices are expected to silently sign in users with SSO without requiring further interaction and will not display the banner. This issue affects Outlook for web users. It will not affect users of new Outlook for Windows, Outlook (classic), Outlook for Mac, Outlook Mobile for iOS and Outlook Mobile for Android.

When this will happen

General Availability (Worldwide): We will begin rolling out late November 2024 (previously late September) and expect to complete by late January 2025 (previously late December).

General Availability (GCC, GCC High, DoD): We will begin rolling out late December 2024 (previously late October) and expect to complete by late February 2024 (previously late December).

How this will affect your organization

Before this migration: Outlook for the web users were not affected by the third-party cookie block in Chrome and Edge and were able to stay signed in unless they signed out or were signed out due to inactivity.

After Outlook for the web migrates to MSAL, Outlook for the web users without device SSO who are using Google Chrome or Microsoft Edge and who have third-party cookie blocking enabled will start seeing the following if Outlook for the web is not able to silently sign in the user with SSO:

• Outlook for the web will display a red banner below the ribbon and require users to sign in when a session is open for more than 24 hours.
• Windowed (deep linked) Mail items and Calendar events will display a blocking dialog requesting users to return to Outlook for the web to sign in when the deep-linked item token expires.
• Independent of Outlook for the web's migration to MSAL, Outlook for the web may include embedded experiences such as apps that may stop functioning due to the third-party cookie block. If this happens, the app may provide an app-specific experience to refresh their token. Alternatively, the user may be able to right-click the app to launch the app in a browser or can choose to refresh the entire Outlook for the web session.

Sign-in error message in red banner below the ribbon in Outlook for the web: "You need to sign in. Your session has expired. You may need to enable pop-ups in your browser for this site. Sign in to continue":

Dialog box requesting users to sign in again:

The authentication rollout will be on by default.

What you need to do to prepare

• In Chrome, enterprise administrators can reset the BlockThirdPartyCookies setting to avoid the block.
• Enterprise administrators can also enable SSO from their Windows devices or add the Microsoft Single Sign On extension for Chrome to ensure their users are not impacted.

This rollout will happen automatically by the specified date with no admin action required before the rollout. You may want to notify your users about this change and update any relevant documentation.