Microsoft Teams Bot入站请求认证方案及自定义头可行性咨询

首先明确核心结论：你无法让Teams发往Bot的入站请求主动携带你自定义的认证Header。Teams平台没有开放给Bot配置出站自定义请求头的功能，所有从Teams官方渠道发往你Bot服务端点的请求，Header字段都是平台固定生成的，没有入口让你提前注入自定义认证信息。

针对你要找的入站请求最优认证方案，可参考以下落地路径：

• 基础必选：用Bot Framework官方内置的认证逻辑，这是安全性最高、维护成本最低的方案。所有Teams发往Bot的请求，都会自动在Authorization请求头携带平台签发的Bearer JWT令牌，你只需要在服务端校验这个令牌的签名合法性、签发方、受众匹配度、有效期即可，这个令牌无法被伪造，本身就可以完全拦截非法请求。
• 自定义认证叠加方案（如果你一定要加自己的认证逻辑，不要指望平台加自定义头，用下面两个替代方案）：
  • 在你配置给Teams的Bot消息端点地址里追加自定义校验参数，比如把端点设置为https://你的服务域名/api/bot/receive?custom_verify=你生成的高复杂度随机密钥，Teams向这个地址发请求时会自动携带该query参数，你可以在服务端优先校验这个参数值是否匹配，再走官方JWT校验，实现双层认证。注意这个自定义密钥要做长度和复杂度要求，定期轮换。
  • 额外加一层来源IP白名单校验，把Teams Bot服务的官方出口IP段加入服务端访问白名单，先拦截非白名单IP的请求，再走后续认证流程，进一步降低非法请求的处理开销。

注意：不要用自定义认证逻辑替代官方的JWT校验，官方JWT校验是Teams Bot安全的基础防线，自定义逻辑只能作为额外的安全叠加层，不能单独使用。

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