authentication.authenticate() fails when app is accessed through MCAS (Defender for Cloud Apps) proxy

[nbelyh]

When a Teams tab app is accessed through Microsoft Defender for Cloud Apps (MCAS) session proxy, authentication.authenticate() breaks because the popup and the opener end up on different origins, and notifySuccess()/notifyFailure() use postMessage which is blocked cross-origin.

How it happens
MCAS rewrites the app URL: app.example.com → app.example.com.mcas.ms

Tab (opener) is on https://app.example.com.mcas.ms
Popup opens auth-start on the same MCAS origin
auth-start redirects to Azure AD. The redirect_uri must use the real domain (app.example.com) because MCAS domains are dynamic and can't be pre-registered in Azure AD
Azure AD redirects back to https://app.example.com/auth-end — now on a different origin than the opener
notifySuccess() calls window.opener.postMessage() → blocked by browser (cross-origin)
Popup stays open, authenticate() never resolves

Expected behavior
authentication.authenticate() should handle the case where opener and popup are on different origins due to MCAS. This is a common enterprise scenario since MCAS is a Microsoft product used with Microsoft 365 tenants.

Environment
@microsoft/teams-js: 2.x
Teams client: Web browser, desktop
MCAS session policy active

Reproduction
Configure an MCAS session policy that proxies a Teams tab app
Open the tab in Teams web while MCAS is active
Trigger a consent flow via authentication.authenticate()
Popup completes Azure AD consent but never closes; authenticate() never resolves

What can you suggest? Is it possible to do authentication with MCAS enabled (having just the id token is not enough for our app)?

[sayali-MSFT]

Hello @nbelyh ,Thank you for bringing this issue to our attention. We will look into it and get back to you shortly.

[sayali-MSFT]

Hello @nbelyh,
The issue occurs because authentication.authenticate() in TeamsJS relies on a popup communicating back to the parent tab using window.opener.postMessage() (notifySuccess). With MCAS (Defender for Cloud Apps session proxy) enabled, the Teams tab runs on a rewritten *.mcas.ms domain while the authentication redirect completes on the original app domain, creating a cross-origin scenario. Due to standard browser security restrictions, postMessage communication is blocked across different origins, preventing notifySuccess() from reaching the opener. As a result, the authentication promise never resolves and the popup remains open.
This is expected browser behavior and highlights a design limitation in TeamsJS, which requires the popup and opener to share the same origin—an assumption that MCAS explicitly breaks through its reverse proxy model. Therefore, authentication.authenticate() cannot reliably work with MCAS in this flow.

As per the documentation,
The authentication.authenticate() flow requires the popup page to call notifySuccess() or notifyFailure() to communicate back to the parent tab. This internally uses window.opener.postMessage (implied by SDK design and behavior).

The recommended approach is to switch to redirect-based authentication (MSAL Auth Code Flow with PKCE) or use Teams SSO (getAuthToken) with a backend OBO flow, as these methods avoid cross-origin popup communication and are fully compatible with MCAS.

[nbelyh]

@sayali-MSFT Thank you for swift response. yes, you understanding of the issue is 100% correct. Unfortunately we cannot go with OBO only, because we want to raise consent for the user (we don't require admin). This is where it fails actually, getting consent from the user. If user (or admin) has consented to the app, the OBO (single-sing-on) works fine.

Do I understand correctly, the only reasonable way out for us would be to use redirect login instead of popup login? I thought maybe there is some configuration where we can add these .mcas.ms domains, so that teams allows these for the popup. Like, maybe, allow it in the Cross-Origin Opener Policy (COOP) header?

[sayali-MSFT]

Hello @nbelyh ,
Popup auth in Teams fails with Conditional Access (.mcas.ms domains) because of cross‑origin restrictions, and it cannot be fixed via COOP or allowlists. The reliable solution is to switch to redirect-based login, while keeping OBO flow unchanged after user consent.

[nbelyh]

@sayali-MSFT The redirect login also does not seem to be possible: I get this:
Refused to display 'https://login.microsoftonline.com/' in a frame because it set 'X-Frame-Options' to 'deny'.
AD does not allow redirect login inside of an IFRAME.

Redirect login only works for a top-level window, not for IFRAME. And Teams app runs in an IFRAME.
Am I missing something here?

[sayali-MSFT]

Hello @nbelyh ,Use Teams SSO (authentication.getAuthToken()) for Entra sign-in instead of redirect login. It runs via the Teams host, avoids iframe restrictions (since Entra blocks rendering in iframes), and is the recommended authentication pattern.
Reference:
1.https://learn.microsoft.com/en-us/microsoftteams/platform/concepts/authentication/authentication
2.https://learn.microsoft.com/en-us/javascript/api/@microsoft/teams-js/authentication?view=msteams-client-js-latest

[nbelyh]

@sayali-MSFT We already do SSO. The thing is we need to raise consent prompt for a user sometimes (for something that is NOT included in the ".default" scope) - for example DevOps authorization, SharePoint authorization. The getAuthToken() cannot do that, all it does is providing ID token that can be exchanged to access token via OBO if consent already granted. In our case, the consent is NOT granted (yet), and the point of the prompt is to give user an opportunity to grant this consent. Am I missing something?

Just to give some context: we have a mature application that is in the Microsoft store for some 5 years already. It authorizes users properly using SSO, so basic authorization flow is not the issue; the issue comes when you want to go to customers that use MCAS (Conditional Access) enabled.

[sayali-MSFT]

Hello @nbelyh,
Teams SSO (getAuthToken) cannot trigger new consent, and popup-based authentication breaks under MCAS due to cross-origin restrictions, so the correct approach is to implement a separate interactive OAuth flow (outside Teams SSO) for incremental consent.

Meantime, we are checking the above scenario with the internal team and let you know the update once we have any.

[sayali-MSFT]

Hello @nbelyh,
we got the update from engineering team that,
This sounds like an MCAS problem. MCAS is doing unnatural things that are breaking the core fundamentals of the web.

If the partner is authenticating with Entra/AAD, then we should recommend they switch to Nested App Auth (NAA):
SSO authentication for nested apps - Teams | Microsoft Learn

This should solve for both their SSO + incremental consent requirements without running into MCAS issues.