Teams SSO

[n1340t]

I have tried many SSO setups but it never works for me. I am developing teams bot solution for my organization and here is my setup.
Development tenant: Teams app
Production tenant: Azure bot service, Azure Active Directory (App registration), AKS to host the bot.
Bot type is User MI hence bot id is tied to client id of Managed Identity. I created a new AAD app for user authentication.

I setup

• redirect uri

• application id uri (api://botid-{botid}

• requestTokenversion is 2

• expose api

• add authorized client id

• api permission is graph, scope is User.Read.

• webApplication info in Teams app manifest: id as client id of new created AAD app

• resource is api://botid-{botid}.

• I setup oauth connection settings in bot service as well with token exchange url same as api://botid-{botid}.

I use signin method to authenticate user. First user was asked to view permission, secondly, user was asked to login, I login with my production tenant account and authentication failed (I got signin failure event) and bot token framework returns 6 digits magic code. Can you shed me some lights? What am I missing here?

[jerbob92]

I think the application ID URI should be api://{domain}/{botid}

[lilyydu]

api://botid-{botId} should work

[jerbob92]

@lilyydu ah my bad, I have recently implemented Tab SSO and assumed it would be the same: https://learn.microsoft.com/en-us/microsoftteams/platform/tabs/how-to/authentication/tab-sso-register-aad#configure-your-app-in-microsoft-entra-id

[n1340t]

@lilyydu I have a question. My AAD client id is different to bot id because my bot is user-assigned MI. Is my application id uri is api://botid-{add_client_id} or api://botid-{botid}?

[corinagum]

@n1340t since your bot is User-assigned MI, the URI on your separate AAD auth app should still be api://botid-{botId} where {botId} is your Managed Identity client ID (the bot ID). Teams requires the botid- prefix format for the SSO flow, and these three values must match:

• webApplicationInfo.resource in your Teams manifest
• Application ID URI ("Expose an API") on your auth AAD app
• tokenExchangeUrl in your Azure Bot OAuth connection settings

[lilyydu]

Hi @n1340t,

Can you make sure the access_as_user scope exists? And can you share what your redirect URI is?

You could also try running teams app doctor against your bot to help diagnose
https://microsoft.github.io/teams-sdk/cli/concepts/sso-architecture?_highlight=sso#setting-up-sso

Could you also compare your setup to our guide here?
https://microsoft.github.io/teams-sdk/cli/guides/user-authentication-setup/#setting-up-sso

As for the signin, did you sideload the bot in the same tenant as your user trying to signin?

(also I reformatted your msg so its easier for me to read)

[n1340t]

Hi @lilyydu thank for answering me.
I can confirm I have access_as_user scope with application id uri: api://botid-{botid}.

Unfortunately I can't sideload the bot in production tenant because the admin doesn't allow. I sideload the bot(teams app) in development tenant but the actual bot backend is hosted in production tenant.

[corinagum]

@n1340t Your setup has the Teams app sideloaded in your dev tenant, but the AAD auth app lives in your production tenant. The SSO flow requires the Teams client to silently acquire a token for the resource URI. Since the Teams client is operating in the context of the dev tenant (where the app is sideloaded), it cannot silently get a token from a production-tenant AAD app unless:

1. The auth AAD app's signInAudience is set to AzureADMultipleOrgs (multi-tenant)
2. The user signed into Teams is in a tenant that can reach the app

If your auth AAD app is single-tenant, SSO will silently fail and fall back to the OAuth card sign-in button. If that also fails (which seems to be what you're experiencing with the magic code), it points to an issue with the OAuth connection configuration itself.

Can you check/share the following?

1. What is the signInAudience on your auth AAD app? (single-tenant vs multi-tenant)
2. What is your redirect URI? It should be exactly https://token.botframework.com/.auth/web/redirect
3. Did you pre-authorize the Teams client IDs under "Expose an API"?

• Teams Desktop: 1fec8e78-bce4-4aaf-ab1b-5451cc387264
• Teams Web: 5e3ce6c0-2b1f-4285-8d4b-75ee78787346

4. In your OAuth connection on the Bot Service, are the ClientId and ClientSecret from your auth AAD app (not the MI)?
5. What failure code do you see in your bot logs? The SDK logs something like: sign-in failed for user "...": <code> -- <message>. The code (e.g., resourcematchfailed, tokenmissing) would help narrow down the exact issue.

[n1340t]

@corinagum the magic code is part of message activity. It comes to my message handler anyway.

How would we make Teams recognize the code? I don't know this information may help but here is my setup:

1. Login to Teams with dev account
2. When login page popup shows up, I use production account because AAD app is in production tenant and production tenant doesn't allow external accounts to login unless admins add them to guest account.

And yes, I just add app.event('signin', ...) as your suggestion to handle sign-in event.
Ps: I can ask admin to add my dev account to production tenant if it's the only way.

[corinagum]

@n1340t Thanks for confirming with a screenshot. My apologies, in my previous comment I said Teams would intercept the magic code and route it as signin/verifyState invoke. However, I did some more digging through the service and this is only true when the authenticating identity = the Teams session user. When signin() is called, the SDK builds a sign-in state that binds the OAuth session to the conversation and bot identity. That is passed to the token service to generate the sign-in link. Teams uses this state to associate the popup with the pending OAuthCard. Because you're signing in with a production account while Teams is logged in as a dev account, the connection breaks. The client can't match the popup completion to the original session, so the code falls through as a regular message activity.

This also means that app.event('signin', ...) handler I suggested won't fire in this setup, since verifyState invoke never arrives.

Unfortunately the magic code flow won't work with this cross-tenant identity mismatch either. Options are:

1. Get admin consent for your Entra app in the dev tenant, allows SSO to work silently
2. Sideload app into production tenant where Entra app lives. SSO would work
3. Have your dev account added as a guest in the production tenant (what you mentioned). You would be able to auth with a matching identity and the magic code flow would work.

Any approach should resolve the cross-tenant identity mismatch.

[n1340t]

Thanks @corinagum, sorry to bother you for so long. Regarding the first recommendation

Get admin consent for your Entra app in the dev tenant, allows SSO to work silently

Do you have a documentation or example somewhere in Microsoft? I have talked to my admin and seems like he doesn't quite understand about the process.
One last thing, can I handle verifyState manually? I have dived into the code, and I think the most important part is api.users.token.get call https://github.com/microsoft/teams.ts/blob/main/packages/apps/src/app.oauth.ts#L81. I assume after I manually call the endpoint with magic code, Bot Framework Token service will release the token and cache the token for next call?

[corinagum]

No bother at all!

Admin consent: The process is for your dev tenant admin to visit this URL and grant consent:

https://login.microsoftonline.com/{dev-tenant-id}/adminconsent?client_id={your-app-client-id}

Replace {dev-tenant-id} with your dev tenant's ID and {your-app-client-id} with your multi-tenant Entra app's client ID. The admin signs in and approves the permissions. After that, SSO should work silently for users in the dev tenant.

Microsoft's general guidance on admin consent

Manual verifyState: Yes, your understanding is correct. You could intercept the magic code in your message handler by checking if the message text matches a 6-digit pattern, then calling api.users.token.get with the code:

   app.on('message', async ({ activity, api, send }) => {
     const text = activity.text?.trim();
     if (/^\d{6}$/.test(text)) {
       const token = await api.users.token.get({
         channelId: activity.channelId,
         userId: activity.from.id,
         connectionName: 'your-connection-name',
         code: text,
       });
       if (token?.token) {
         await send('Sign-in complete!');
         return;
       }
     }
     // ... rest of your message handling
   });

Once redeemed with the code, the Token Service caches the token. Subsequent signin() calls should return the cached token directly without requiring another sign-in flow.

That said, this is a workaround for the cross-tenant identity mismatch. If you can get admin consent working, SSO is the cleaner long-term path.

[n1340t]

Many thanks to @corinagum for such helpful support. I have asked admins to grant consent and it works for us. The strange thing is it didn't work last night. Was it because of caching in global Teams and AAD servers around the globe? Anyway, I am able to signin and signout without issues now.

[corinagum]

Yes I would assume caching, especially for auth. Entra ID propagation isn't instant, and it's possible the token service and client also cache SSO results. Glad you got it working! I'm going to close this discussion as resolved.