多租户Angular+ASP.NET Core应用MSAL授权同意问题求助

看起来你遇到的核心问题是登录时没触发对WebApi的授权同意，导致客户租户里没创建WebApi的服务主体，进而WebApi调用Graph时权限不足。我来帮你一步步排查和解决：

1. 替换.default范围为WebApi的具体权限范围 #

你的consentScopes里写了api://xxxxxxxxxxxxxxxxxx/.default，这个范围是静态权限集合，它包含的是管理员预先同意的所有权限，不会触发用户层面的授权同意弹窗。你需要把它替换成WebApi应用注册里定义的具体范围，也就是api://xxxxxxxxxxxxxxx/api_usage。

修改后的consentScopes配置如下：

consentScopes: [
  'user.read',
  'openid',
  'profile',
  'api://xxxxxxxxxxxxxxx/api_usage' // 替换成你实际的WebApi范围
],

2. 确认WebApi的范围允许用户同意 #

登录Azure门户→WebApi应用注册→「公开API」→找到你定义的api_usage范围，检查**谁能同意？**的设置：

• 如果是多租户应用，要选择「所有人（多租户和个人Microsoft账户）」或者「组织内的用户」
• 不要选「仅管理员同意」，否则普通用户登录时不会看到该权限的同意提示

3. 检查客户端应用的API权限配置 #

进入客户端应用注册→「API权限」：

• 确保已添加WebApi的api_usage权限（类型为Delegated权限）
• 该权限状态保持「未授予管理员同意」即可（多租户场景下，用户自行同意就能触发服务主体创建；若管理员预先同意，用户登录时不会看到弹窗，但租户仍会生成服务主体）

4. 验证WebApi的OBO流程配置（针对Graph调用场景） #

WebApi调用Graph必须使用**On-Behalf-Of（OBO）**流程，你需要确保：

• WebApi应用注册里已添加Graph的Delegated权限（比如你测试用的Calendar.Read、Place.Read）
• 这些Graph权限无需管理员预先同意（除非你确定所有客户租户都会提前授权），这样OBO流程才能动态获取用户同意的权限

额外测试建议 #

如果修改后仍未看到WebApi的同意提示，可以尝试：

• 清空浏览器的localStorage和Cookie，重新登录（避免旧权限缓存影响）
• 使用全新的租户用户账号测试（确保该账号未同意过旧的权限配置）

这样调整后，用户登录时应该会看到包含WebApi权限的同意弹窗，客户租户里也会自动创建WebApi的服务主体，WebApi后续调用Graph的OBO流程也能拿到正确的权限令牌了。

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