Single-tenant bot compatibility with cross-tenant Graph API requests

Question

Single-tenant bot compatibility with cross-tenant Graph API requests

MK 20

I'm looking for clarity on the intended way to model a Teams integration that can be installed (as a Teams app from the store) in a customer's tenant. The requirements for the integration are:

Send messages, via the Bot Framework API
Handle the authentication process during Teams app install, i.e. OAuth callback handling and subsequent display of a list of channels from the authenticated Team(s) so that an end user can select where they want their notifications to be delivered via the bot. This functionality is handled via the Graph API

As I understand it, multi-tenant bots (deployed via Azure) have been deprecated. However, single-tenant bots can be published to the Store within a Teams app, and can send cross-tenant messages to end user tenants where the Teams application has been installed. I have confirmed that this works correctly.

My outstanding question is: which application (the Azure Bot app or the Teams app) should be registered in Entra for use with the Graph API, in order to display a list of available channels to a user during app installation? I know that for a legacy multi-tenant bot, you can simply use the Bot app itself (i.e. the Graph API client ID and secret map directly to the bot's Application ID and password).

Can I expect a single-tenant Azure bot to work in the same way when configured in Entra with the "Supported account types" set to "Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant)"? Will this setting allow successful cross-tenant API requests to the Graph API, or should a separate application (likely the Teams app that wraps the bot app) be registered with the Graph API in Entra?

The Graph API endpoints we leverage are:

Would any application which shares the same MicrosoftAppTenantId with the published Teams application work?

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Hi @MK

Based on the current Teams/Bot Framework guidance, I would separate two concepts here:

The Azure Bot / Bot Framework identity used for bot messaging
The Microsoft Entra application used to obtain Microsoft Graph tokens

A bot configured as Single Tenant in Azure Bot Service can still be used in a Teams app distribution scenario, and Microsoft’s Teams Developer Portal documentation states that bots created in Developer Portal are single tenant by default. The same documentation also clarifies that multi-tenant bot configuration in Azure Bot Service is deprecated, but multi-tenant Microsoft Entra app registrations remain supported, and that these app registrations are separate from the bot tenant configuration in Azure Bot Service. It also explicitly states that a bot configured as single tenant in Azure Bot Service can use a multi-tenant application.

Reference: Manage your apps in Developer Portal

For the Bot Framework / proactive messaging side, the important configuration is that the bot requests the correct Bot Framework token using the tenant where the bot’s backing Microsoft Entra app is registered. Microsoft’s documentation notes that for single-tenant bots, the developer must include the tenant ID as part of the environment variables when requesting the access token.

Reference: Add authentication to your Teams bot

For the Microsoft Graph side, the deciding factor is not simply whether the Azure Bot itself is single tenant. Graph access depends on the Microsoft Entra application used as the OAuth client, the permissions configured on that app, and whether the user or admin in the customer tenant has consented to those permissions. Teams app permissions documentation states that Microsoft Graph API permissions are managed in Microsoft Entra ID, and that the user or administrator must grant the correct permissions through a consent process.

Reference: Permissions in Teams app

For the APIs mentioned:

To list the Teams a signed-in user has joined, Microsoft Graph supports GET`` ``/me/joinedTeams or GET`` ``/users/{id`` ``|`` ``user-principal-name}/joinedTeams. The least privileged delegated permission listed is Team.ReadBasic.All; application permission Team.ReadBasic.All is also listed.
To list channels in a team, Microsoft Graph supports GET`` ``/teams/{team-id}/channels. The least privileged delegated permission listed is Channel.ReadBasic.All; the documentation also notes that Teams members cannot see private or shared channels they are not members of in the response.

For an installation-time experience where an end user signs in and selects a Team/channel for notifications, a delegated Graph flow is usually the right model, because the result should reflect what that signed-in user is allowed to see. If the app needs tenant-wide discovery or app-only access, then application permissions and admin consent would be required.

Regarding your question about whether any application that shares the same MicrosoftAppTenantId as the published Teams app would work, sharing the same MicrosoftAppTenantId only indicates that the app registrations belong to the same home tenant. For Graph, the client application must still be the correct OAuth client, must request the required Graph permissions, and must have consent in the customer tenant. The token must be issued for the tenant/resource being accessed, and the Graph call must be made with a token that contains the appropriate delegated scopes or application roles.

Hope this helps clarify the separation between the Bot Framework identity and the Microsoft Graph OAuth client.

If the answer is helpful, please click "Yes" 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.

MK 20 Reputation points

2026-07-13T16:45:09.37+00:00

Hi @Michelle-N , thanks for your response!

All of the above is clear. But, I'm still not sure whether I can use my single-tenant bot as the Entra-registered application for interacting with the Graph API. Do I need to use a separate application for this use case?
Michelle-N 20,735 Reputation points Microsoft External Staff Moderator

2026-07-14T13:52:18.2033333+00:00

Hi @MK

Thank you for the update.

Based on the current guidance, you do not necessarily need a separate Entra application if your existing bot's backing Entra app is suitable for both scenarios. The important distinction is that the Bot Framework identity and the Graph OAuth client are logically separate concerns, even if they are backed by the same Entra app registration.

In practice, if the Entra application associated with your bot:

is configured as a multitenant Entra application,

exposes the required redirect URIs,

requests the necessary Microsoft Graph permissions (for example, delegated permissions appropriate for listing Teams and channels),

and receives the required user or admin consent in the customer tenant,

then that same Entra app can generally be used as the OAuth client for obtaining Graph tokens. The fact that the bot is configured as single-tenant in Azure Bot Service does not automatically prevent the associated Entra app from being used for cross-tenant Graph consent and token acquisition.

A separate Entra application would typically only be needed for architectural, security, or operational reasons, such as wanting to isolate Graph permissions from the bot identity, use different consent models, or manage credentials separately.

Thank you.
MK 20 Reputation points

2026-07-14T14:51:08.7266667+00:00

Thank you!!
Michelle-N 20,735 Reputation points Microsoft External Staff Moderator

2026-07-14T14:53:05.4666667+00:00

Hi @MK

Thank you very much for the update.

If you found the hints I provided helpful, I would appreciate it if you could Vote Up this thread so other users can refer to this information.

If you have any other related questions, please let me know.