Azure AD中Yammer的user_impersonation委托权限管理员同意的影响

1. 权限覆盖问题的缓解 #

使用v2端点并指定具体作用域（比如仅user_impersonation）进行管理员同意时，不会覆盖已配置的其他权限（比如你的Sites.Read.All应用权限）。之前出现的覆盖问题，本质是未指定作用域时，管理员同意的是应用注册中所有请求的权限集合；而v2端点的精准作用域指定，能实现仅同意目标权限，保留已有的其他权限配置。

2. 租户级委托同意的实际效果 #

• 管理员同意user_impersonation后，租户内所有用户使用该应用时，无需再单独授权这个权限，直接通过OAuth流就能获取代表用户的访问令牌，访问该用户有权限的Yammer发布数据，大幅简化用户操作流程。
• 这个同意操作完全独立于Sites.Read.All应用权限，不影响你后续通过客户端凭据流获取应用级令牌访问SharePoint附件的流程，两类权限的令牌获取和使用逻辑是分开的。

3. 安全层面的潜在风险 #

• 租户级同意user_impersonation意味着应用可以代表任何租户用户访问其Yammer数据，若应用存在令牌泄露、权限校验不严等漏洞，可能导致大量用户的Yammer内容泄露，务必确保应用的安全性，比如严格存储令牌、实现细粒度的权限校验。
• 要确认业务是否真的需要租户级同意：如果你的应用仅面向部分用户使用，也可以考虑让用户自行同意user_impersonation（只要该权限属于允许用户同意的范围），缩小授权范围降低风险。

4. 后续权限管理注意事项 #

• 后续调整权限时，务必继续通过v2端点指定具体作用域进行同意操作，避免误选所有权限导致现有配置被覆盖。
• 定期在Azure AD门户中查看应用的已同意权限列表，区分委托权限和应用权限，遵循最小必要原则，及时清理不再需要的权限。

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