发现权限和同意

  • 3 分钟

与 Microsoft 标识平台集成的应用程序遵循的授权模型可让用户和管理员控制数据的访问方式。

Microsoft 标识平台实现 OAuth 2.0 授权协议。 OAuth 2.0 是可让第三方应用代表用户访问 Web 托管资源的方法。 与 Microsoft 标识平台集成的任何 Web 托管资源都有一个资源标识符（也称为“应用程序 ID URI”）。

下面是 Microsoft Web 托管资源的一些示例：

  • Microsoft Graph： https://graph.microsoft.com
  • Microsoft 365 邮件 API：https://outlook.office.com
  • Azure Key Vault：https://vault.azure.net

这同样适用于已与 Microsoft 标识平台集成的任何第三方资源。 以上任意资源还可以定义一组可用于将该资源的功能划分成较小区块的权限。 将资源的功能分割成小的权限集时，可将第三方应用构建为只请求执行其功能所需的权限。 用户和管理员能够知道应用可以访问哪些数据，

在 OAuth 2.0 中，这些类型的权限集称为“范围”。 它们通常也称为“权限”。 在 Microsoft 标识平台中，权限以字符串值形式表示。 应用通过在 scope 查询参数中指定权限来请求所需的权限。 标识平台支持多个定义明确的 OpenID Connect 范围以及基于资源的权限（通过将权限值追加到资源的标识符或应用程序 ID URI 来指示每个权限）。 例如，权限字符串 https://graph.microsoft.com/Calendars.Read 用于请求在 Microsoft Graph 中读取用户日历的权限。

应用往往是通过在发往 Microsoft 标识平台授权终结点的请求中指定范围来请求这些权限。 但是，某些高特权权限只能通过管理员同意来授予。 可以通过使用管理员同意终结点来请求或授予这些权限。

注意

在对 Microsoft 标识平台的授权、令牌或同意终结点请求中，如果在 scope 参数中省略资源标识符，则假定资源为 Microsoft Graph。 例如，scope=User.Read 等效于 https://graph.microsoft.com/User.Read。

权限类型

Microsoft 标识平台支持两种类型的权限：委托的访问权限和仅限应用的访问权限。

  • 委托的访问权限由包含登录用户的应用使用。 对于这些应用，由用户或管理员同意应用请求的权限， 当应用调用目标资源时，它被委托了充当已登录用户的权限。

  • “仅限应用的访问权限”由无需用户登录即可运行的应用使用，例如，作为后台服务或守护程序运行的应用。 只有管理员才能同意仅限应用的访问权限。

Microsoft 标识平台中的应用程序必须获得同意才能访问所需的资源或 API。 应用可能需要了解多种类型的许可才能成功访问。 在定义权限时，还需要了解用户如何获取应用或 API 的访问权限。

有三种同意类型：静态用户同意、增量和动态用户同意和管理员同意。

在静态用户同意方案中，必须在 Azure 门户的应用配置中指定应用所需的所有权限。 如果用户（或管理员，视情况而定）尚未对此应用授予同意，则 Microsoft 标识平台会提示用户提供同意。 静态权限还使管理员能够代表组织中的所有用户进行同意。

尽管在 Azure 门户中定义应用的静态权限能保持代码的简洁性，但可能会给开发人员带来几个问题：

  • 应用需要在用户首次登录时请求所有可能需要的权限。 这可能会导致冗长的权限列表，而让最终用户在初始登录时打消审批应用程序访问权限的念头。

  • 应用需要事先知道可能访问的所有资源。 很难创建能够访问任意数量资源的应用。

使用 Microsoft 标识平台终结点，可以忽略在 Azure 门户的应用注册信息中定义的静态权限，而以递增方式请求权限。 可以在一开始请求一组最少的权限，随着客户使用其他应用功能时再请求更多的权限。

为此，可以在请求访问令牌时，通过在 scope 参数中包含新的范围来指定应用所需的范围 - 无需在应用程序注册信息中预定义这些范围。 如果用户尚未同意添加到请求的新范围，则系统会提示他们仅同意新的权限。 增量许可或动态许可仅适用于委托的权限，而不适用于仅限应用的访问权限。

重要

动态许可有时十分方便，但对于管理员许可的权限而言，可能会带来很大的挑战，因为管理员许可体验在许可时不知道这些权限。 如果你需要管理员特权权限，或者应用使用动态许可，则必须在 Azure 门户中注册所有权限（而不仅仅是需要管理员同意的权限子集）。 这使租户管理员能够代表其所有用户同意。

应用需要访问特定的高特权权限时，必须执行管理员同意。 管理员同意可以确保管理员在授权应用或用户访问组织中的高特权数据之前拥有某些额外的控制权。

代表组织执行管理员同意仍需要为应用注册静态权限。 如果需要管理员代表整个组织授予同意，请在应用注册门户中为应用设置这些权限。 这会减少组织管理员设置应用程序所需的周期数。

在 OpenID Connect 或 OAuth 2.0 授权请求中，应用可使用范围查询参数来请求所需的权限。 例如，当用户登录应用时，应用会发送类似于以下示例的请求 添加换行符以提高可读性。

GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&scope=
https%3A%2F%2Fgraph.microsoft.com%2Fcalendars.read%20
https%3A%2F%2Fgraph.microsoft.com%2Fmail.send
&state=12345

scope 参数是应用程序所请求的委托权限列表（以空格分隔）。 每个权限都是通过将权限值附加到资源的标识符（应用程序 ID URI）来指示的。 在该请求示例中，应用需要相应的权限来读取用户的日历，以及以用户身分发送邮件。

在用户输入其凭据之后，Microsoft 标识平台将检查是否有匹配的用户同意记录。 如果用户过去未曾同意所请求权限的任何一项，并且管理员尚未代表整个组织同意这些权限，则 Microsoft 标识平台会请求用户授予请求的权限。