AzureAD单租户多站点多应用场景权限组织最佳方案咨询

核心架构选型 #

采用Azure AD原生安全组作为权限载体，不做自定义权限存储，全链路可通过Graph API自动化管理，核心逻辑分三层：

• 按权限粒度创建两类安全组，统一使用固定命名规则：
  • 站点全权限组：命名格式为sec-loc-{location标识}-all，绑定对应站点下所有应用的访问权限
  • 单应用权限组：命名格式为sec-loc-{location标识}-app-{app标识}，绑定对应站点下指定应用的访问权限
• 所有4个自有企业应用、4个OAuth2接入站点统一在Azure AD应用注册平面管理，OAuth2站点直接配置对应重定向URI即可，和自有企业应用无管理差异
• 所有应用统一配置组声明下发规则，访问令牌中仅携带与当前应用所属站点匹配的组信息，应用侧直接校验令牌内的组声明即可完成权限判断，无需实时调用Graph API

对应需求的落地示例 #

针对你提到的User1权限需求，操作路径如下：

需求：User1可访问Location1站点下的App1，可访问Location2站点下的App2、App3；支持单站点全应用权限开放
落地操作：

1. 预先创建3个单应用权限组：sec-loc-loc1-app1、sec-loc-loc2-app2、sec-loc-loc2-app3，同时创建2个站点全权限组sec-loc-loc1-all、sec-loc-loc2-all
2. 将User1加入上述3个单应用权限组；若后续需要给其他用户开放Location1全应用权限，直接将对应用户加入sec-loc-loc1-all组即可，无需逐个绑定单应用权限
3. 在App1的可选声明配置中，设置组声明筛选规则：仅返回ID匹配sec-loc-loc1-app*、sec-loc-loc1-all前缀的组，避免令牌携带无关权限信息导致体积过大；Location2下的App2、App3按相同逻辑配置对应站点的组筛选规则
4. 应用侧拿到访问令牌后，只要检测到令牌内包含对应单应用权限组、或站点全权限组的ID，直接放行对应访问即可

Graph API 集成参考 #

自研系统做权限自动化管理时，直接调用以下原生接口即可，无需额外封装：

• 组生命周期管理：调用/groups接口创建、删除权限组，可通过组的扩展属性字段存储绑定的location标识、app标识、权限类型，后续查询无需解析组名
• 组成员管理：调用/groups/{group-id}/members/$ref接口添加/移除组成员，支持批量操作
• 应用声明配置：调用/applications/{app-object-id}/optionalClaims接口配置组声明的筛选规则，针对不同应用定制下发的权限组范围
• 权限校验兜底：如果用户所属组数量超过阈值导致令牌内组声明被截断，应用侧可调用/users/{user-id}/checkMemberGroups接口批量传入待校验的权限组ID，单次请求最多可校验1000个组，性能满足绝大多数场景
• 避坑提示：不要选择应用角色（App Role）实现该场景，App Role为单应用维度绑定，跨应用、跨站点批量授权时操作量是安全组方案的3倍以上，后续维护成本极高

运维注意事项 #

• 所有权限组统一使用安全组类型，不要使用Microsoft 365组，后者会自动生成Exchange、SharePoint等附属资源，权限边界不纯粹
• 组名固定使用sec-前缀，后续做权限查询、审计时可直接通过startswith(displayName, 'sec-')筛选所有权限组，无需遍历全租户组资源
• OAuth2接入站点需在对应应用注册中准确配置重定向URI、访问令牌受众，避免出现跨站点令牌混用的安全问题

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