SSO Token Fails in Outlook Desktop but Works in OWA

Dear Diluka Hewage

Thank you for reaching out to Microsoft Q&A forum with your questions.

The error (AADSTS50076) occurs specifically in the Outlook Desktop client because the Single Sign-On (SSO) token acquired by the add-in lacks an "mfa" entry in its amr (Authentication Method Reference) claim. This claim is part of the token's payload and indicates the methods used for authentication (e.g., password + multifactor). Our backend validates this for security, so tokens without "mfa" are rejected.

To Answer your inquiries:

1. Is the absence of "mfa" in the Outlook Desktop SSO token the actual reason why the add-in fails with MFA-related errors?

Yes, this is likely the direct cause if your backend validation logic checks for the presence of "mfa" in the amr (Authentication Method Reference) claim array within the JWT payload of the access token acquired via office.auth.getAccessToken()``.

The amr claim is a standard OpenID Connect/JWT attribute that lists the authentication methods used to authenticate the user (e.g., ["pwd"] for password-only, or ["pwd", "mfa"] for password + multifactor authentication). Microsoft Entra ID (formerly Azure AD) includes "mfa" in amr only when an MFA challenge was satisfied during the token issuance or propagation process. If your backend uses this claim to enforce MFA compliance (e.g., rejecting tokens without it for security reasons), the absence would trigger validation failures, leading to errors like the one shown in your screenshot (AADSTS50076, which relates to MFA enforcement via configuration changes or policy triggers).

This aligns with your reproduction: the token works when "mfa" is present (post-CA policy) but fails without it. Note that while amr is optional in some token configs, it's commonly relied upon for MFA verification in Graph API integrations, as it provides proof of authentication strength without needing separate policy checks.

2. Why would Outlook Desktop issue a token without "mfa", while OWA includes it?

This discrepancy stems from how the two clients handle Single Sign-On (SSO) authentication via the Primary Refresh Token (PRT) in Microsoft Entra ID, combined with differences in session management and prompt behaviors:

• PRT and Claim Propagation: Both Outlook Desktop and OWA leverage the PRT, a device-bound refresh token issued during Entra ID device registration (e.g., on Entra-joined or hybrid-joined Windows devices), for seamless SSO. The PRT can carry an "mfa" claim if it was obtained or renewed via an MFA-authenticated flow (e.g., Windows Hello for Business or an interactive MFA prompt). When the client requests an access token (like via getAccessToken() for your add-in), Entra ID propagates the PRT's claims, including "mfa" in amr, to the resulting token. If the PRT lacks the "mfa" claim (e.g., it was issued via password-only auth or the MFA imprint has expired), the downstream token won't include it either.
• Outlook Web App (OWA): Tokens consistently include "mfa" because web sessions trigger fresh MFA challenges more reliably.
• Outlook Desktop: Uses cached credentials via the Primary Refresh Token (PRT) for seamless sign-ins, which may not reflect recent MFA if the session is long-lived or predates an MFA requirement.

This leads to inconsistent behavior across clients but doesn't affect the add-in's functionality in OWA.

3. Is enforcing MFA through Conditional Access the correct way to guarantee consistent behavior across Desktop and OWA?

Yes, this is the recommended and most reliable approach for consistent MFA enforcement in Office add-ins and Microsoft 365 apps. CA policies in Entra ID allow granular control over authentication strength, ensuring MFA challenges occur when needed and updating the PRT accordingly for both clients.

• Why It Works Here: Your test setup (targeting the user, Office 365 resources, and your add-in's Enterprise App, with "any device") forced an interactive re-sign-in, imprinting the "mfa" claim on the PRT. This propagates to SSO tokens in both Desktop (via WAM) and OWA (via browser SSO), resolving the inconsistency. Without this, Desktop's silent flows can bypass prompts if the PRT is still valid but lacks the claim.

I hope I was able to clarify your concern, if you have any additional question, feel free to comment below. I be more than happy to assist.  

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".      

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.