Blog Post

IIS Support Blog
6 MIN READ

Azure Bot Identity | Application with identifier 'x' was not found in the directory 'Bot Framework'

manojdixit's avatar
manojdixit
Icon for Microsoft rankMicrosoft
Dec 05, 2025

Azure Bot Service empowers developers to build intelligent, enterprise-grade conversational experiences that seamlessly connect users across channels at scale. Each Azure Bot Service has a unique identity Id and type. With MultiTenant Bot creation deprecated as of July 31, 2025, newly created bots are now SingleTenant by default—and if identity configuration is not set up correctly, this can lead to authentication failures such as: “AADSTS700016: Application with identifier 'xxx' was not found in the directory 'Bot Framework'.” In this blog, we’ll break down Bot identity fundamentals, service-to-service authorization, and provide practical migration guidance for transitioning existing MultiTenant bots to the SingleTenant model.

TL;DR

  • Every Azure Bot has a fixed identity (MicrosoftAppId) tied to either an App Registration or a Managed Identity—it cannot be changed or reused.
  • Azure Bot supports three identity types:
    • User-Assigned Managed Identity
    • Single-Tenant App Registration
    • Multi-Tenant App Registration (deprecated after July 31, 2025)
  • Bots involve three auth flows:
    1. Client → Channel (platform-specific)
    2. Channel ↔ Bot (core system auth using OAuth2 + Entra ID)
    3. User sign-in (optional; uses Authorization Code Flow)
  • The error “AADSTS700016: Application with identifier 'xxx' was not found in the directory 'Bot Framework'” happens when the Bot application tries to request tokens from the botframework.com tenant instead of its home tenant while the App registration is set as SingleTenant.
  • BotFrameworkAdapter Class (Microsoft.Bot.Builder) | Microsoft Learn is hardcoded to the Bot Framework tenant and does not work with Single-Tenant or Managed Identity bots. In Bot-Builder SDK (retires after Dec 2025), CloudAdapter Class (Microsoft.Bot.Builder.Integration.AspNet.Core) | Microsoft Learn supports SingleTenant and UserAssigned-MSI bots and MicrosoftAppType needs to be configured to reflect the correct Bot Identity. 
  • With announcement of the Bot-Builder SDK deprecation, we recommend moving to The M365 Agents SDK which retains many Bot Builder concepts with ability to create next generation Agents with orchestration, observability and more secure options authentication.  This also offers flexible and more secure options for token aquisition. 

Skip directly to the "Channel (2) ↔ Bot (3) Authorization" section if you want to understand why the error occurs. 

Azure Bot Identity

Every Azure Bot Service has a unique Id (also known as MSAAppId or MicrosoftAppId) which you can find in Azure Portal -> Azure Bot Resource -> Configuration if the Bot is created:

This MSAAppId corresponds to either the Client ID of Application Registration in Microsoft Entra ID or Managed Identity in Azure . This is Id is tied to the respective Bot Service from creation until deletion, cannot be modified or reused for a different Bot resource. Closely related to this is the concept of the Azure Bot Identity Type and can be one of the following:

References:

Identity and Authorization

As described in Navigating Azure Bot Networking: Key Considerations for Privatization, an Azure Bot Solution consists of below components:

  • Clients (1): User-facing application used to consume/converse with Bot solutions. Examples include Web Chat Widget, Teams, Slack etc.  
  • The Bot Service: This managed SaaS umbrella includes configuration management, channel services and token services. Services are made available with the <service>.botframework.com endpoints.
  • The Bot Application (2): Using the Bot/Agents SDK or Composer, you create an HTTP-based application that encapsulates your functional and conversational logic, including recognition, processing, and storage. The Bot application operates using the Bot Framework Activity Specification. The Bot application exposes a public messaging endpoint for receiving activities (messaging endpoint).
  • Channel Connectors (3): While Azure Bot Service provides two native channels—Direct Line and Web Chat—it is designed to be highly extensible and supports integration with additional clients and communication platforms through external channels. These channels are implemented and operated by their respective providers and run within their own managed data centers. The bot’s messaging endpoint is not exposed directly to end users; instead, users interact with the bot via channel connectors, which handle session management, activity routing, and authentication on behalf of the client. Different clients, such as Teams and Slack, represent messages and activities uniquely. Since Bot applications understands and responds with activities as defined in the Bot Framework Activity Specification, channels are responsible for transforming activities and forwarding them to the application.

There are 3 Authentication/Authorization flows in a Bot solution. 

  • Client (1) to Channel (2) Authentication - This flow is platform-specific and is implemented by the channel owner. It governs how an end-user or client application authenticates with the channel before any interaction reaches the bot. For example, the Direct Line channel requires a token or secret to establish trust, as described in Direct Line Authentication in Azure AI Bot Service - Bot Service | Microsoft Learn
  • Channel (2) <-> Bot (3) Authorization - This flow is channel-independent and is consistent across all Azure Bot channels. Communication between the channel and the bot occurs via bi-directional HTTPS calls secured using OAuth2 JWT Access Tokens issued by Microsoft Entra ID. Both the channel and the bot validate each other by exchanging these tokens. This mechanism is what directly relies on the Azure Bot Identity type (Managed Identity, Single-Tenant App, or legacy Multi-Tenant App) and is the primary focus of this blog.

  • User Authentication - This is an optional flow enables end users to authenticate within the chat experience so the bot can identify the user, access protected user data or perform actions on the user’s behalf (e.g., schedule meetings, access emails). User authentication is implemented using the "Authorization Code Flow" and supports multiple identity providers, including Microsoft Entra ID. When Entra ID is used, the bot can authenticate users using the same App Registration as the bot identity, or a separate App Registration, depending on security and design requirements. This user sign-in process is independent of the Channel-to-Bot authorization flow and is not affected by the bot’s identity type.

Channel (2) <-> Bot (3) Authorization

As we see in the "Outbound Flow: Bot to Channel", the Bot Application typically uses OAuth 2.0 client credentials flow on the Microsoft identity platform - Microsoft identity platform | Microsoft Learn. The token authority (endpoint) used for this flow depends on the Bot Identity Type, as documented in Authenticate requests with the Bot Connector API - Bot Service | Microsoft Learn.

The error "Application with identifier 'xxx' was not found in the directory 'Bot Framework'" happens when:

  • The Bot’s Application Registration is configured as Single-Tenant
    (Supported account types = Accounts in this organizational directory only)
  • The Bot application requests a token from the Bot Framework tenant:
    • https://login.microsoftonline.com/botframework.com/oauth2/v2.0/token
  • Since the App Registration is Single-Tenant, only the home tenant can issue tokens.
  • The Bot Framework tenant is not the home tenant → token issuance fails.

All the operations shown in diagram except business logic is automatically handled by the SDK (BotSDK or AgentsSDK) but the Developer gets control correct token endpoint. 

Migration fromMultiTenant SingleTenant to in the Bot code:

I hope it helps. 

Updated Dec 05, 2025
Version 1.0
No CommentsBe the first to comment