AAD Access Token按API授权改造咨询：限制Service-A调用指定API

基于你的现状（client_credentials模式授权，Service-B验证正常），要实现API级白名单且不修改Service-B这个resource，以下是几种落地方案：

方案1：在Access Token中嵌入细粒度权限声明 #

利用OAuth2的scope字段或自定义Claim，给Service-A分配仅允许访问API-1的权限：

• 授权端配置：在授权服务器给Service-A的client_id配置专属权限范围，比如service-b:api-1，移除原来的全量权限scope（比如service-b:*）
• Service-B验证增强：在token验证通过后，新增权限校验逻辑：
  1. 解析token中的scope或自定义Claim（比如allowed_apis）
  2. 将当前请求的API路径映射为标识（如/api/v1/xxx对应api-1）
  3. 验证该标识是否在token允许的列表内，不在则返回403
• 优势：符合OAuth2标准，权限信息随token传递，无需额外存储

方案2：API网关层基于Client ID的路由拦截 #

如果Service-B前端有API网关，直接在网关层配置路由规则：

• 网关规则配置：添加规则：当请求来源的client_id（从token解析）为Service-A时，允许/api-1/**路径，拒绝/api-2/**路径
• 校验逻辑：网关先完成token有效性验证，再根据client_id和请求路径匹配规则，不符合则直接拦截返回403
• 优势：无需修改Service-B业务代码，仅需网关配置，侵入性极低

方案3：Service-B内部新增权限校验中间件 #

在Service-B的请求链路中加入自定义中间件，实现基于Client ID的API权限控制：

• 中间件实现：
  1. 从token中解析出client_id
  2. 维护一个权限配置表（可存在配置文件或数据库），记录client_id -> 允许访问的API列表映射（如Service-A: ["api-1"]）
  3. 拦截请求时，匹配当前API标识与配置表，不匹配则返回403
• 优势：配置灵活，可动态更新权限列表，无需重启服务

以上方案均无需修改Service-B的resource标识，仅通过扩展授权配置、网关规则或内部校验逻辑实现API级白名单控制。

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