如何基于Azure API Management设计微服务架构的身份认证与授权策略

针对你的两个疑问的解答 #

疑问1：SPA应该获取哪个微服务的令牌？

不需要获取任意一个下游微服务的令牌，直接申请APIM对应的AAD应用的访问令牌即可。这个方案完全对齐你之前自研网关的认证逻辑，前端不需要做大幅改造，也符合网关统一收口身份校验的设计原则。

疑问2：能不能单独给APIM注册AAD应用，由APIM通过OBO流换取下游微服务令牌？

完全可以，这是Azure官方推荐的微服务网关认证的标准落地方案，具体实现流程如下：

• 完成AAD应用侧的配置：
  1. 单独注册APIM对应的AAD应用，暴露API访问scope，同时为该应用授予3个下游微服务的委托访问权限，完成管理员权限同意。
  2. 更新SPA对应的AAD应用配置，将APIM应用的scope添加到授权允许列表中。
• 完成前端侧的配置：
  前端发起带PKCE的授权码流登录请求时，将aud参数指定为APIM的应用ID，请求的scope设置为APIM应用暴露的访问scope即可，前端拿到的令牌仅能用于访问APIM网关，无法直接调用下游微服务，符合安全隔离要求。
• 完成APIM侧的策略配置：
  1. 在APIM的全局或者对应API的 inbound 阶段添加validate-jwt或者validate-azure-ad-token策略，校验前端传入的APIM令牌的合法性，非法请求直接拦截返回401。
  2. 校验通过后，通过APIM内置的send-request策略调用AAD的OBO接口，用前端传入的令牌换取对应下游微服务的访问令牌，还可以配置APIM的缓存策略存储换取后的微服务令牌，减少重复请求AAD的开销。
  3. 将换取到的微服务令牌添加到转发请求的Authorization头中，再转发给对应的下游微服务即可。

补充说明：如果你的微服务不需要很细的用户身份上下文，也可以选择APIM用客户端凭证流获取下游微服务的令牌，不过OBO流能完整传递用户身份信息，更适合有用户维度权限控制的场景。

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