Bot Framework Security and Privacy Frequently Asked Questions

Each bot is its own service, and developers of these services are required to provide Terms of Service and Privacy Statements per their Developer Code of Conduct. For more information, see bot review guidelines.

Yes. Your bot can be hosted anywhere on the Internet. On your own servers, in Azure, or in any other data center. The only requirement is that the bot must expose a publicly accessible HTTPS endpoint.

Users have a way to report a misbehaving bot via the bot's contact card in the directory. Developers must abide by Microsoft terms of service to participate in the service.

If you have an outbound firewall that blocks traffic from your bot to the Internet, you'll need to allowlist the following URLs in that firewall:

• login.botframework.com (Bot authentication)
• login.microsoftonline.com (Bot authentication)
• westus.api.cognitive.microsoft.com (for Luis.ai NLP integration)
• *.botframework.com (channels)
• state.botframework.com (backward compatibility)
• login.windows.net (Windows login)
• login.windows.com (Windows login)
• sts.windows.net (Windows login)
• Other URLs for specific Bot Framework channels

Bot Framework Services is hosted in Azure data centers world-wide and the list of Azure IPs is constantly changing. That means allow-listing certain IP addresses may work one day and break the next as the Azure IP Addresses change.

Creating a bot in the Azure portal requires Contributor access either in the subscription or in a specific resource group. A user with the Contributor role in a resource group can create a new bot in that specific resource group. A user in the Contributor role for a subscription can create a bot in a new or existing resource group.

Using the Azure CLI, a role-based access control approach can support custom roles. If you want to make a custom role with more constrained permissions, the set below allows the user to create and deploy a bot that also supports LUIS, QnA Maker, and Application Insights.

"Microsoft.Web/*",
"Microsoft.BotService/*",
"Microsoft.Storage/*",
"Microsoft.Resources/deployments/*",
"Microsoft.CognitiveServices/*",
"Microsoft.Search/searchServices/*",
"Microsoft.Insights/*",
"Microsoft.Insights/components/*"

1. All authentic Bot Framework requests are accompanied by a JWT token whose cryptographic signature can be verified by following the authentication guide. The token is designed so attackers can't impersonate trusted services.
2. The security token accompanying every request to your bot has the ServiceUrl encoded within it, which means that even if an attacker gains access to the token, they can't redirect the conversation to a new ServiceUrl. This is enforced by all implementations of the SDK and documented in our authentication reference materials.
3. If the incoming token is missing or malformed, the Bot Framework SDK won't generate a token in response. This limits how much damage can be done if the bot is incorrectly configured.
4. Inside the bot, you can manually check the ServiceUrl provided in the token. This makes the bot more fragile if the service topology changes, so while this is possible, it's not recommended.

In the Web Chat control, there are two mechanisms to assure that the proper user is signed in.

1. Magic code. At the end of the sign-in process, the user is presented with a randomly generated 6-digit code (magic code). The user must type this code in the conversation to complete the sign-in process. This tends to result in a bad user's experience. Additionally, it's still susceptible to phishing attacks. A malicious user can trick another user to sign-in and obtain the magic code through phishing.

   Warning

   The use of the magic code is deprecated. Instead, you should use Direct Line enhanced authentication, described below.

2. Direct Line enhanced authentication. Because of the issues with the magic code approach, Azure AI Bot Service removed its need. Azure AI Bot Service guarantees that the sign-in process can only be completed in the same browser session as the Web Chat itself. To enable this protection, you must start Web Chat with a Direct Line token that contains a list of trusted origins, also know as trusted domains, that can host the bot's Web Chat client. With enhanced authentication options, you can statically specify the list of trusted origins in the Direct Line configuration page. For more information, see Direct Line enhanced authentication.

The identity and access management (IAM), is a framework (policies and technologies) to allow proper people to have appropriate access to technology resources. For more information, see Identity management.

The Bot Framework provides the following identification mechanisms:

• Bot authentication. Determines if a request came from a legitimate source. It's controlled by the bot connector service and enables secure communication between a bot and a channel. For more information, see Bot authentication.

• User authentication. It enables the bot to access secured online resources on behalf of the user. The industry standard OAuth is used to authenticate the user and authorize the bot to access the resources. For more information, see User authentication.

In summary, the Bot Framework handles the service-to-service authentication (bot authentication), essentially validating that a request did indeed come from a proper channel. The bot is responsible for handling lower levels of authentication. You can apply a filter so your bot only accepts requests from a particular tenant ID, or you can require your users to authenticate with some OAuth service (user authentication).

You have two different options for restricting incoming messages that your bot processes.

• If you're dealing with secure data, it's definitely recommended to use OAuth to authenticate the users.

• Using middleware is another good option. In the Teams channel, for example, you can create middleware to get the tenant ID from the Teams channel data. The middleware can then decide whether to let the incoming activity continue on to your bot logic or to instead return an error message.

  Warning

  You can't prevent Teams from sending you messages from various tenants, nor can you prevent someone from installing your bot if they have your app manifest. All you can do is to prevent your bot from processing the undesired messages.