Azure企业管理员能否对动态应用类型权限范围执行管理员同意？
能否为动态应用类型权限范围（非委托权限）启用管理员同意？
我有一个Azure应用，使用多个权限范围，本次讨论限定为：
- Mail.Read
- Mail.ReadBasic
- Mail.Send
我希望允许企业管理员为其企业内所有用户动态同意任意读取和写入权限的组合。例如，有的管理员仅授予Mail.ReadBasic，有的则授予Mail.Read + Mail.Send。
需要注意的是，这些必须是应用类型权限范围，而非委托权限，因为我们需要在用户进入应用前，使用获取到的令牌进行一些后台处理。显然，./default无法满足需求，因为它会要求管理员同意应用中定义的所有权限。
查阅文档时，部分内容显示这可能可行（“你可以改用动态同意，在运行时添加希望出现在同意界面的权限，而非使用/.default”），而另一些内容则表示必须使用/.default。
目前我已尝试以下方案：
- 客户端凭据流
- 仅允许
./default作为范围，但通过此方式获取的令牌可用于企业内所有用户 - 在adminconsent API中使用
common或{tenant_id}似乎没有区别
- 仅允许
- 授权码流
- 这是我们应用中针对单个用户使用的流程
- 在此流程中，管理员仅需接受我指定的权限，但获取到的令牌表现异常：
- 我可以使用该令牌读取所有用户的配置文件（仅用于测试的User.Read.All范围）
- 其他范围（如Mail.Read和Mail.Send）仅对管理员有效，即使同意界面已勾选
代表你的组织同意
- 此外，此流程似乎仅支持
delegated（委托）权限类型（已在Azure管理面板的企业应用部分确认）
- 应用角色
- 我曾设想在应用内创建角色，并为每个角色分配一组权限范围，但未取得太多成效，不确定这是否是其预期用法。
目前看来，我们可能需要创建4个分别具有以下权限的应用：
- Mail.Read
- Mail.ReadBasic
- Mail.Read + Mail.Send
- Mail.ReadBasic + Mail.Send
我发现相关文档有些令人困惑，怀疑自己要么误解了部分内容，要么遗漏了关键环节。
核心结论
对于应用权限（Application Permissions），Azure AD目前不支持动态管理员同意——也就是无法让管理员在同意流程中自由选择特定的权限组合。应用权限的管理员同意只能通过/.default范围触发，这会要求管理员同意该应用注册中预先配置的所有应用权限，没有选择性的空间。
文档矛盾的原因
你看到的“动态同意”相关描述，仅适用于委托权限（Delegated Permissions），不适用于应用权限。而服务主体令牌请求的文档明确要求应用权限必须使用/.default，这是应用权限的强制规则。
对已尝试方案的解析
- 客户端凭据流：这是应用权限的标准使用流程，确实只能用
/.default范围。获取的令牌拥有该应用注册下所有已同意的应用权限，能访问租户内所有用户的对应资源——这是应用权限的设计特性，它赋予应用本身全租户的访问权限，而非针对单个用户。 - 授权码流：该流程本质是为委托权限设计的，即使管理员勾选“代表组织同意”，也只是将委托权限授予租户内所有用户，但令牌仍需绑定用户上下文。像Mail.Read这类委托权限，默认仅能访问令牌所属用户的邮件，只有User.Read.All这类明确标记为全租户的委托权限，才能访问所有用户数据，所以这个方案无法满足你的后台无用户上下文处理需求。
- 应用角色：应用角色用于在你的应用内部实现权限管控，比如给用户分配不同的操作权限，但它无法拆分Azure AD授予的应用权限范围，因此不适合你的场景。
可行解决方案
你提到的创建多个应用注册，每个对应一组特定的权限组合，是目前最直接、可靠的方案：
- 每个应用注册独立配置所需的应用权限（比如一个仅配置Mail.ReadBasic，另一个配置Mail.Read+Mail.Send）
- 企业管理员可以针对每个应用单独完成管理员同意，选择符合自身需求的权限组合
- 你的应用可以根据客户的选择，使用对应应用的凭据发起客户端凭据流，获取对应权限的令牌进行后台处理
另外一个可选（但不推荐）的思路是：让管理员在完成全权限同意后，手动进入Azure AD的企业应用页面，删除不需要的权限。但这个操作依赖客户管理员的配合，且容易出错，远不如多应用方案可控。
内容的提问来源于stack exchange，提问作者VukNovakovic
