New Teams Desktop App SSO Fails with "Access Denied" in Tab (Web Works)

Question

My Teams tab uses Azure AD SSO and works perfectly in the Teams web client. In the new Teams desktop app, authentication fails immediately with "Access denied for the resource" (PII removed).

• Manifest validated: correct validDomains, openid, User.Read, reply URLs
• @microsoft/teams-js@2.0.0 used; no errors in web dev tools
• Desktop logs show silent SSO failure; no token returned
• Org has fully migrated to new Teams (classic retired July 2025)

What causes silent SSO to fail in the new Teams desktop client when it succeeds in web, and how can I resolve it

Answer 1

Please note that our forum is a public platform, and we will modify your question to hide your personal information in the description. Kindly ensure that you hide any personal or organizational information the next time you post an error or other details to protect personal data.

Hi Schenck Shay

Thank you for reaching out to Microsoft Q&A forum

I have conducted some research, and the behavior you see stems from differences in authentication flows between the Teams web and desktop clients, particularly in how they handle the on-behalf-of (OBO) token exchange required for tab SSO. In the web client, the browser's existing Entra ID session enables seamless silent authentication via shared context.

In contrast, the new desktop client uses an isolated OneAuth broker that does not reuse browser sessions, enforcing stricter OBO validations where the Teams client must be explicitly authorized as a "known client application" in the tab's Entra ID app registration to redeem tokens for scopes like User.Read. The "Access denied" error typically indicates either a resource/scope mismatch between what your application requests and what Azure AD has been configured to provide in the desktop context, or missing admin consent that the web client may have bypassed through cached credentials.

Therefore, you can follow instructions below to see if your concern can be resolved:

1. Checked Entra ID Sign-in Logs → Under Microsoft Entra ID > Monitoring & health > Sign-in logs, you can filter by your app’s Client ID and found failures reason with resource access denied messages
2. Verified API Permissions & Authorized Clients → In App registrations > Expose an API, you have to made sure your Application ID URI matches the code (api://<domain>/{clientId}) and added Teams desktop and mobile ID as authorized client apps. Admin consent was also granted.
3. Verify Token: In your tab’s JavaScript, log the full getAuthToken() response to check for errors:

const token = await microsoftTeams.authentication.getAuthToken({ silent: true });
if (!token) {
  // Prompt user
  await microsoftTeams.authentication.authenticate({
    url: '/auth-start.html', // Your auth page
    width: 600,
    height: 535
  });
  // Then retry silent
}

You can use jwt.ms to decode and validate any returned tokens

This method should restore silent SSO in desktop. If sign-in logs reveal a different sub-error, adjust scopes/consent accordingly.

Let me know the log details for more targeted advice

Best regards

---

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.