Teams向Bot发消息失败，请求排查Authorization配置是否正确

嘿，我之前也碰到过几乎一模一样的Teams Bot问题——Postman发消息能正常接收，但通过Teams客户端发就石沉大海，你怀疑Authorization相关配置出问题，方向完全没错！咱们一步步拆解排查：

1. 先搞懂核心差异：Postman vs Teams转发请求 #

Postman是直接调用你的Bot API，用的是你自己生成的测试token；但Teams发送消息时，是微软Teams服务先接收消息，再转发请求到你的Bot，所以请求头的身份验证逻辑完全不同：

• Teams转发的Authorization头格式是Bearer <微软生成的access-token>，不是你Postman里用的测试token
• 这个token的受众（aud claim）必须是你的Bot的App ID，颁发者（iss claim）也得是微软合法的身份服务地址

2. 重点检查Authorization头的验证逻辑 #

• 如果你的Bot代码里硬编码了Postman用的测试token，那肯定会直接拒绝Teams的请求，赶紧改成动态验证逻辑
• 用JWT解析工具（本地解析就行，别把token外传）解析Teams请求里的token，看看aud是不是你的Bot App ID，iss是不是https://login.microsoftonline.com/<你的租户ID>/v2.0或者Teams特定的颁发者
• 如果你用的是Bot Framework SDK，SDK已经内置了验证逻辑，别自己瞎改，确保Azure配置里的Bot App ID和App Password和代码里的配置完全一致

3. 别漏了Teams专属的请求头 #

除了Authorization，Teams转发请求时还会带几个关键头，缺了或者错了都可能导致Bot不认：

• MicrosoftAppId：值必须是你的Bot的App ID，Bot服务要校验这个值是否匹配
• Content-Type：必须是application/json，而且请求体得严格符合Teams的Activity Schema（比如要有type、from、conversation这些必填字段）
• X-MS-Teams-TenantId：有些Bot逻辑依赖这个租户ID，缺失的话可能导致处理失败

4. 看日志！看日志！看日志！ #

这是最快定位问题的办法：

• 在Bot服务里打印所有请求头和验证环节的错误信息，看看Teams请求进来时，是不是有token验证失败、签名不匹配、受众错误之类的日志
• 如果临时关闭验证逻辑（仅测试用，别放生产！）后能收到Teams消息，那100%是验证环节的问题

5. 检查Bot的Azure注册配置 #

• 确保Azure Portal里Bot的「消息端点」和你Postman调用的完全一致，而且必须是HTTPS（Teams不接受HTTP端点）
• 检查Bot的权限配置，有没有添加TeamsChannelMessage.Send这类必要权限，并且完成了管理员同意（如果是租户级Bot的话）

6. 对比Postman和Teams的请求头 #

用抓包工具或者Bot服务日志，把Postman的请求头和Teams的请求头放在一起对比：

• 看看Authorization头的token结构差异
• 有没有Teams里有但Postman没有的头，或者反过来

一般来说，按照这个流程排查，很快就能找到问题——大概率是Authorization的验证逻辑没适配Teams的token，或者某个Teams专属头没被正确处理。

内容的提问来源于stack exchange，提问作者axbeit