Bot Framework Connector rejects valid app-only token for its own conversation (401 "Authorization has been denied")

Question

Environment

Tenant ID[Moderator note: personal info removed]Tenant ID[Moderator note: personal info removed]Azure AD App ID / Bot ID[Moderator note: personal info removed]Teams App ID[Moderator note: personal info removed]App namevignesh-collab-appSupported account typesMultiple organizations (multi-tenant)Conversation ID[Moderator note: personal info removed]Conversation type1:1 personal chatSummary

Sending any message into an existing, live 1:1 Teams conversation with our own registered bot fails with:

401 {"message":"Authorization has been denied for this request."}

This occurs even with a freshly issued, valid app-only OAuth token for this exact App ID, called directly against the Bot Framework Connector REST API — bypassing our own service entirely. The bot has never successfully sent a single message into this conversation; all inbound messages from the user are delivered correctly, but every outbound send is rejected.

Steps to reproduce

1. Obtain a client-credentials token:

      curl -X POST https://login.microsoftonline.com/botframework.com/oauth2/v2.0/token \
        -d "grant_type=client_credentials" \
        -d "client_id=[Moderator note: Personally Identifiable Information removed]" \
        -d "client_secret=<secret>" \
        -d "scope=https://api.botframework.com/.default"
   

   → Succeeds. Returns a valid token with aud: https://api.botframework.com, appid: b7aa8a45-9e2f-4d37-844a-d143a30936ce, issued by the botframework.com multi-tenant authority.
2. POST an activity into the live conversation using that token:

      curl -X POST "https://smba.trafficmanager.net/amer/0cfce438-99e9-407d-8a61-05dc462f9cab/v3/conversations/[Moderator note: Personally Identifiable Information removed]r/activities" \
        -H "Authorization: Bearer <token>" \
        -H "Content-Type: application/json" \
        -d '{"type":"message","text":"test"}'
   

   → Fails: {"message":"Authorization has been denied for this request."}

Diagnostic evidence (all client-side causes ruled out)

• Reproduced identically across two independently created apps (fresh App IDs, fresh client secrets, fresh Bot Management registrations, fresh DB config each time) — not specific to one app.
• Client secret confirmed valid (expires 2028, not expired), and confirmed identical between Azure Portal "Certificates & secrets" and Teams Developer Portal "Client secrets" tab.
• Bot confirmed registered in Teams Developer Portal → Bot Management with this exact Bot ID.
• Messaging endpoint confirmed correctly configured.
• Confirmed not a stale conversation reference: the conversation.id used above is identical to the one on the most recent live inbound activity from Teams for this exact conversation.
• Confirmed not a service URL/region issue: retried step 2 against both smba.trafficmanager.net/in/ and the tenant-specific smba.trafficmanager.net/amer/{tenantId}/ (the latter taken directly from the live inbound activity's own serviceUrl) — identical 401 on both.
• Confirmed Teams itself recognizes this bot as the conversation's bot: the live inbound activity's recipient field is {"id":"[Moderator note: Personally Identifiable Information removed]","name":"vignesh-collab-app"}.
• App Validation, Publish to org, and Teams Admin Center approval all completed for this Teams app.
• Separately, Teams App Validation reports "Unable to upload the manifest.zip file in MS Teams" (policy 1140.4.1) for this same app package — despite the package being verified spec-correct (icons at correct 192×192/32×32 RGBA dimensions, clean flat zip structure, valid manifest schema, no composeExtensions/messageHandlers).

Expected behavior

A valid app-only token for the bot that owns a conversation should be accepted by the Connector for that conversation, per standard Bot Framework client-credentials authentication.

Actual behavior

The Connector rejects the request with a generic 401, with no further detail, regardless of app identity, secret, service URL, or conversation freshness — all of which have been independently verified correct.

Ask

Please check the backend Bot Channels/Connector registration and conversation-authorization state for App ID [Moderator note: personal info removed] in tenant [Moderator note: personal info removed]. Given the identical failure across three separately registered apps in this same tenant, we suspect a tenant-level or backend registration inconsistency rather than a per-app misconfiguration.

Answer 1

Hi @Vignesh Murugesan,

Based on your description, the symptom pattern you've outlined  closely matches a similar case that was previously reported in the Microsoft Q&A forum. 

One troubleshooting step that proved successful in that case was to request the client-credentials token from your own tenant authority rather than the botframework.com authority, while keeping the same scope. The resulting token was then used for the Bot Framework Connector call. 

See more here: Keep getting 401 Unauthorized "Authorization has been denied for this request." trying to send message to channel with Azure Bot Framework - Microsoft Q&A 

Since your issue reproduces across three apps all using the botframework.com authority, this is worth ruling out first. 

If the 401 persists after switching the authority, it may be necessary to have the issue examined from the backend. Unfortunately, community forum members don't have access to the internal tools or service-side telemetry required to verify those configurations or investigate the conversation authorization state.  

In that situation, I'd recommend opening a support ticket with Microsoft (If you're an end user, please contact your admin).

Tips: You can switch off the Support Assistant as shown in the screenshot, then type a few short characters into the search box and select Get Help. After that, wait for the Contact Support button to appear and click it. At the final step, be sure to clearly describe your request in the description fields so the support engineers can quickly understand your issue and assist you more effectively.   

Once engaged, a support engineer can review the backend registration state, investigate the conversation authorization flow, and validate any service-side configuration that isn't visible from the tenant side. If necessary, they can also escalate the issue to the appropriate product team for deeper analysis. 

I hope this helps narrow down the next steps and directs you to the right support team if additional assistance is required.