多API Web应用的OAuth抽象：AzureAD集成与Spring Security配置咨询

整体架构定位 #

你的Web应用作为OAuth2客户端（兼OIDC依赖方），通过Azure AD完成用户登录并获取Access Token；后端的多个API作为OAuth2资源服务器，验证来自Web应用（或其他服务）的Access Token后提供服务。

Azure AD资源建模方案 #

1. 每个API是否需配置独立Client ID？ #

建议按业务边界/安全域拆分注册：

• 如果API属于不同业务域（比如订单API和用户API）、有不同的敏感级别（如财务API vs 普通查询API），或者需要独立的权限管控、审计追踪，必须为每个API注册独立的Azure AD应用（即独立Client ID）。这种方式能清晰划分资源边界，方便后续扩展（比如给不同API配置不同的条件访问规则）。
• 如果多个API属于同一业务单元、逻辑高度耦合且安全要求一致，可以共用一个Client ID，但要注意后续权限管理的粒度问题，不推荐长期采用这种方式。

Azure AD中，每个资源服务器对应一个“API注册”，其Client ID就是Access Token中的aud（受众）字段，资源服务器通过校验该字段确保Token是发给自己的。

2. 权限采用共用池还是各API专属更优？ #

优先选择各API专属权限，原因如下：

• 权限是与资源绑定的，专属权限能清晰对应API的操作（比如order-api.read、user-api.write），符合最小权限原则，避免过度授权。
• 共用权限池会导致权限模糊，用户/客户端难以明确授权范围，也不利于后续的权限审计和调整。
• 若存在跨API的通用操作（比如全局只读权限），可以单独定义通用权限，但仍需与各API的专属权限分开管理。

在Azure AD中，可通过**委派权限（Delegated Permissions）定义用户发起请求的权限，通过应用角色（App Roles）**定义服务间调用的权限，均建议按API维度划分。

Spring Security配置要点 #

Web应用（OAuth2客户端/OIDC） #

• 引入依赖：spring-boot-starter-oauth2-client
• 核心配置示例：

  # Azure AD客户端配置
  spring.security.oauth2.client.registration.azure.client-id=你的Web应用Client ID
  spring.security.oauth2.client.registration.azure.client-secret=你的Web应用Client Secret
  spring.security.oauth2.client.registration.azure.scopes=openid, profile, email, order-api.read, user-api.read
  
  # Azure AD提供商配置
  spring.security.oauth2.client.provider.azure.issuer-uri=https://login.microsoftonline.com/你的租户ID/v2.0
  

• 配置登录回调地址（需在Azure AD应用注册中同步配置），通过spring.security.oauth2.client.registration.azure.redirect-uri指定。
• 使用OAuth2AuthorizedClientService获取Access Token，用于调用后端API。

后端资源服务器 #

• 引入依赖：spring-boot-starter-oauth2-resource-server
• 核心配置示例（以订单API为例）：

  # JWT验证配置
  spring.security.oauth2.resourceserver.jwt.issuer-uri=https://login.microsoftonline.com/你的租户ID/v2.0
  # 指定当前API的Client ID（Azure AD中API注册的Client ID）
  spring.security.oauth2.resourceserver.jwt.audience=订单API的Client ID
  

• 方法级权限校验：使用@PreAuthorize注解，比如：

  @GetMapping("/orders")
  @PreAuthorize("hasAuthority('SCOPE_order-api.read')")
  public List<Order> getOrders() {
      // 业务逻辑
  }
  

• 旧API迁移：对于原HTTP Basic认证的API，可临时配置双认证支持（JWT + Basic），逐步切换至纯JWT认证；SOAP API需将JWT验证逻辑集成到SOAP拦截器或Spring Security过滤器链中。

额外建议 #

• 启用Azure AD条件访问，为不同API配置不同的安全策略（比如MFA要求）。
• 使用Azure AD的应用注册权限审批流程，严格管控客户端的权限申请。
• 配置Spring Security审计日志，结合Azure AD日志实现全链路的安全审计。

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