Microsoft Graph for Office 365 - Azure AD应用程序权限

博客地址：http://blog.csdn.net/FoxDave

前面两篇文章，我们介绍了基于Azure AD终结点创建应用程序。在本篇文章中，我们来看一下可用的权限以及如何将它们授予用户或Azure AD应用程序。

权限的类型

访问Microsoft Graph终结点需要发起请求的应用程序或用户被授予合适的权限。这些权限的类型可以是托管权限或应用程序权限。

托管的 (代理)
托管权限，需要在请求时一同提供用户上下文。事实上是应用程序以用户的名义在调用Microsoft Graph请求。因此，所需权限是用户和应用程序所拥有权限的集合体。
在请求时使用这两个有效权限中的交叉部分。如果应用程序被授予了权限而用户不具有该权限，那么应用程序就无法完成指定的请求。
如果我们对访问令牌进行解码，托管权限会以“scopes”的形式显示。判断权限是否分配并满足条件的第一步最好是检查访问令牌是否有合适的/期望的“scopes”。

应用程序 (app-only或没有用户)
应用程序权限，不需要用户上下文执行。这种权限的应用通常为后台运行的服务或无人值守应用程序。在请求Microsoft Graph时只判定授予应用程序的权限。
Azure AD的域管理员往往需要对应用程序权限的申请进行批准。Azure AD有一个叫做应用程序管理员的角色能够批准Azure AD应用程序的托管权限和除Microsoft Graph和Azure AD Graph之外的应用程序权限。虽然在Graph这个系列中不适合使用，但应该有所了解。更多信息可以访问
https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#available-roles
如果我们对访问令牌进行解码，应用程序权限会以“roles"的形式显示。同样的，判断权限时先检查”roles“。

权限命名模式
Microsoft Graph中的所有权限都依照特定的模式有一个内部名称：

• Resource.Operation.Constraint

例如：User.Read.All = 当前目录所有用户的读取权限。

Resource和Operation部分总是指定的，但Constraint是可选的用来定义服务/目录中的潜在范围。如果不列出Constraint，则应用到资源的权限为当前登录用户。

例如：User.Read = 当前登录用户的读取权限。

下图是Microsoft Graph中对既定场景的操作所需权限的示例，完整的以资源分组的权限列表请访问Microsoft Graph permissions reference。

注意：所需权限应秉持最小权限原则。

练习

• 创建用户
• 获取邮件列表