Azure API网关架构下外部应用获取JWT Token的最佳实践是什么

方案一：外部应用直接向Azure AD请求Token的合理性 #

• 这个方案本身是OAuth 2.0客户端凭证流的标准实现，完全合理，不存在架构层面的问题。
• 你担心的「外部应用直接调用我方内部Azure AD」的顾虑可以通过Azure AD的应用注册权限隔离解决：只需要给每个外部合作方单独创建应用注册，分配仅对应该合作方可调用API的最小范围权限，不需要开放Azure AD的其他管理权限，外部应用只能调用OAuth 2.0的Token端点，无法访问租户内的其他Azure AD资源，安全性有足够保障。
• 该方案的优势是无需额外开发维护Token获取接口，直接复用Azure AD原生的安全能力，包括限流、防暴力破解、Secret轮转审计等能力，不需要自己重复造轮子。

方案二：API网关暴露get-jwt-token接口的安全方案 #

• 只有当你因为合规要求不能对外暴露Azure AD的Token端点时，才需要考虑这个方案，它不属于首选方案。
• 该方案下不推荐使用Basic Auth做接口防护：Basic Auth的凭证只是做了明文编码而非加密，即使全程走HTTPS仍存在凭证泄露、暴力破解的风险，且没有原生的凭证轮转、权限粒度管控能力。
• 如果必须使用该方案，建议的防护逻辑：
  • 给每个合作方发放唯一的、有效期可配置的API密钥，密钥仅在首次发放时展示，后端存储加盐哈希值，不存明文
  • 接口添加严格的限流策略，单IP、单密钥的请求频率限制在合理区间
  • 所有请求必须走HTTPS，禁止HTTP访问
  • 接口层添加请求日志审计，所有Token发放请求全链路可追溯
  • 网关转发到Azure AD之前做参数校验，仅允许分配给对应合作方的scope、client_id请求，防止越权获取其他范围的Token

主流最佳实践 #

• 优先选择方案一，也就是让外部合作方用标准OAuth 2.0客户端凭证流直接从Azure AD获取Token，这是Azure官方推荐的对外API访问的标准模式，也是全球SaaS服务商通用的做法。
• 配套的管理规则：
  • 要求合作方定期轮转Client Secret，最长有效期不超过1年，可直接使用Azure AD原生的Secret过期提醒能力
  • 针对不同合作方分配独立的应用注册，每个应用注册仅开放最小必要的API权限范围
  • 在API网关层添加JWT的自定义校验，除了Azure AD的基础校验之外，额外校验Token中的scope、aud声明是否和请求的API匹配，防止越权调用
  • 针对安全性要求更高的场景，可以要求合作方使用证书代替Client Secret做身份认证，进一步降低Secret泄露的风险

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