同一应用内AD双场景实现咨询：规避admin consent需求

Great question! You don’t have to split into two separate app registrations—there’s a cleaner way to handle both scenarios within a single Azure AD app while keeping the basic login flow free of admin consent requirements. Here’s how you can pull this off:

核心思路：分层权限+动态请求+用户/租户区分 #

1. 在单应用注册中配置分层权限 #

首先，给你的应用设置两组不同的权限：

• 基础登录场景：只添加无需管理员同意的委托权限，比如User.Read（这是实现用户登录、访问基础个人信息的最小权限）。普通用户自己就能同意这个权限，不需要管理员审批。
• 企业场景：添加你需要的高权限（比如Group.Read.All、Directory.ReadWrite.All用于管理停用用户）。这些权限需要管理员同意，但你不需要给所有用户开启——只针对特定企业租户/用户组开放。

2. 用应用角色或租户ID区分用户类型 #

要判断给用户请求哪类权限，你可以：

• 分配应用角色：在应用注册中创建一个EnterpriseUser角色，然后给企业租户的用户/组分配这个角色。用户登录时，检查他们是否拥有该角色——如果有，就请求企业级权限；如果没有，就只走基础登录的权限范围。
• 按租户ID过滤：如果你的企业用户都来自特定已知租户，就检查登录令牌中的租户ID。对于这些租户，触发企业权限流程；其他租户则使用基础流程。

3. 在代码中动态调整OAuth权限范围 #

在你的应用认证逻辑里，根据用户类型动态设置scope参数：

• 针对普通用户：

  scope=openid profile email User.Read
  

• 针对企业用户：

  scope=openid profile email User.Read Group.Read.All
  

企业租户的管理员只需要一次性授予高权限的同意——之后该租户的用户登录时就不会再收到重复的同意提示。

什么时候考虑拆分两个应用注册 #

如果你的两个场景业务逻辑完全独立，或者你需要绝对的权限隔离（避免普通用户意外触发高权限请求），创建MyApp Simple和MyApp Enterprise也是合理的选择：

• MyApp Simple：只包含基础的、用户可自主同意的权限，完全不需要管理员审批。
• MyApp Enterprise：包含所有企业级权限，需要管理员提前同意。

这种方式在权限隔离上更彻底，但会增加维护成本——你需要管理两个应用注册、分别更新配置、维护两套认证流程。

最终建议 #

优先选择单应用+动态权限+角色/租户过滤的方案。它能保持用户体验的一致性（不需要切换不同应用），减少管理负担，同时依然能实现必要的权限边界。只有当你有严格的隔离需求、无法通过分层权限满足时，再考虑拆分两个应用。

内容的提问来源于stack exchange，提问作者Benjamin E.