getAuthToken for Teams app in Outlook fails

[LeonYasoon]

Hello team.

When calling microsoftTeams.authentication.getAuthToken({ resources: [] }) inside a Teams app that is also available in outlook, this fails and produces a bunch of these errors in the console:

It seems like this is some sort of loop the getAuthToken call gets stuck in for while and the fails. The same app in Teams works just fine.

[LeonYasoon]

I found this in the response of https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize which gets called first:

            "strServiceExceptionMessage": "AADSTS50196: The server terminated an operation because it encountered a client request loop. Please contact your app vendor.",
            "strTraceId": "dc70ab09-8375-4905-82db-22430e972d00",

[Nivedipa-MSFT]

Thanks for bringing this issue to our attention. We will check and update you soon.

[Nivedipa-MSFT]

Hello @LeonYasoon - The error indicates that the Outlook iframe is blocking the authentication redirect because allow-top-navigation is not enabled. As a result, getAuthToken() falls back to interactive login instead of silent SSO.

Solution: Pre-authorize the Outlook client IDs in your Entra ID app registration under Expose an API → Authorized client applications:

bc59ab01-8403-45c6-8796-ac3ef710b3e3 (Outlook desktop)
d3590ed6-52b3-4102-aeff-aad2292ab01c (Outlook web/M365)

If these are not set, silent SSO will not work in Outlook, leading the SDK to try an interactive redirect, which is blocked by the sandboxed iframe, causing a retry loop.

Additionally, remove resources: [] from the call and use getAuthToken() without parameters.

Reference: Extend Personal Tab to Microsoft 365 - Teams | Microsoft Learn

Please let us know if you have any further query here.

[LeonYasoon]

Hey @Nivedipa-MSFT

The client ids are pre-authorized in the Entra app already.
The getAuthToken call sometimes works by the way.
I will update our code to do the call without resources: [] and let you know if that made it more consistent.

[LeonYasoon]

Followup: Removing resources: [] from the getAuthToken call did not change the behaviour at all.

This feel like a rate-limit type error. It works fine for the first few screens and then it blocks.

[Nivedipa-MSFT]

We are checking this internally, we will update you soon.

[Nivedipa-MSFT]

Hello @LeonYasoon,
In Outlook, the app is hosted in a sandboxed iframe/webview. When microsoftTeams.authentication.getAuthToken() requires any interactive Azure AD step (consent, CA/MFA, new session, etc.), the underlying AAD flow tries to perform a top‑level redirect, which is blocked by the sandbox. This causes the auth flow to loop and eventually fail, even though the same code works in Teams, which has fewer navigation restrictions.

Recommended solutions:

Best long‑term fix: Use Nested App Authentication (NAA) with MSAL, which is designed for apps embedded in Teams, Outlook, and Microsoft 365 and avoids getAuthToken entirely.
Ref Doc: https://learn.microsoft.com/en-us/microsoftteams/platform/concepts/authentication/nested-authentication

Workaround: Attempt getAuthToken() first, and if it fails, fall back to microsoftTeams.authentication.authenticate() (popup‑based auth), which works when auth UI is blocked in iframes.
Ref Doc: https://learn.microsoft.com/en-us/javascript/api/@microsoft/teams-js/authentication?view=msteams-client-js-latest

[LeonYasoon]

Thanks for providing the workarounds. We found that the getAuthToken promise never resolves nor throws when it encounters the blocked login loop in outlook, so it would be hard to detect if we have a case of having to call authenticate(). But for now, we implemented some client side caching mechanisms for the cases when we DO get a token so we just call getAuthToken() much less anyways, which seems to increase stability a lot.

You can close this ticket if you want, since the problem can be resolved by your workarounds im sure.