服务间应用

警告

本内容适用于较旧版本的 Azure AD v1.0 终结点。为新项目使用 Microsoft 标识平台。

服务到服务应用程序可以是需要从 Web API 获取资源的守护程序或服务器应用程序。有两个适用于本部分的子方案：

需要调用基于 OAuth 2.0 客户端凭据授予类型的 Web API 的守护程序

在这种情况下，了解一些事项是很重要的。首先，无法与守护程序应用程序进行交互，这要求应用程序具有自己的标识。守护程序的一个示例是批处理作业，或在后台运行的操作系统服务。这种类型的应用程序使用应用程序标识请求访问令牌，并向 Azure AD 显示其应用程序 ID、凭据（密码或证书）和应用程序 ID URI。身份验证成功后，守护程序从 Azure AD 接收访问令牌，然后用于调用 Web API。
需要调用基于 OAuth 2.0 On-Behalf-Of 草稿规范构建 Web API 的服务器应用程序（如 Web API）

在此方案中，假设用户已在本机应用程序中进行身份验证，并且此本机应用程序需要调用 Web API。 Azure AD 颁发 JWT 访问令牌来调用 Web API。如果 Web API 需要调用另一个下游 Web API，则可以使用代理流将用户的标识委托给第二层 Web API 并进行身份验证。

图表

守护程序或服务器应用程序到 Web API 的关系图

首先，服务器应用程序需要以 Azure AD 本身身份进行身份验证，而无需任何人工交互（例如交互式登录对话框）。它向 Azure AD 的令牌终结点发出请求，提供凭据、应用程序 ID 和应用程序 ID URI。
Azure AD 对应用程序进行身份验证，并返回用于调用 Web API 的 JWT 访问令牌。
通过 HTTPS，Web 应用程序使用返回的 JWT 访问令牌在请求的授权标头中以“Bearer”标识添加 JWT 字符串，以请求 Web API。然后，Web API 会验证 JWT 令牌，如果验证成功，则返回所需的资源。

下面讨论的流假定用户已在另一个应用程序（如本机应用程序）上进行身份验证，并且其用户标识已用于获取对第一层 Web API 的访问令牌。

本机应用程序将访问令牌发送到第一层 Web API。
第一层 Web API 将请求发送到 Azure AD 的令牌终结点，提供其应用程序 ID 和凭据，以及用户的访问令牌。此外，请求是使用on_behalf_of参数发送的，该参数指示 Web API 正在请求新令牌来代表原始用户调用下游 Web API。
Azure AD 验证第一层 Web API 是否有权访问第二层 Web API 并验证请求，将 JWT 访问令牌和 JWT 刷新令牌返回到第一层 Web API。
通过 HTTPS，第一层 Web API 随后通过在请求的 Authorization 标头中追加令牌字符串来调用第二层 Web API。只要访问令牌和刷新令牌有效，第一层 Web API 就可以继续调用第二层 Web API。

请参阅守护程序或服务器应用程序到 Web API 方案的代码示例：服务器或守护程序应用程序到 Web API

单租户 - 对于应用程序标识和委托的用户标识案例，守护程序或服务器应用程序必须在 Azure AD 中的同一目录中注册。 Web API 可配置为公开一组权限，这些权限用于限制守护程序或服务器对其资源的访问。如果使用委派的用户标识类型，服务器应用程序需要选择所需的权限。在应用程序注册的 API 权限 页中，选择 “添加权限 ”并选择 API 系列后，选择 “委派权限”，然后选择你的权限。如果使用应用程序标识类型，则不需要此步骤。
多租户 - 首先，守护程序或服务器应用程序配置为指示其正常运行所需的权限。当目标目录中的用户或管理员向应用程序提供许可时，对话框会显示此所需权限列表，使应用程序可供其组织使用。某些应用程序只需要用户级权限，组织中的任何用户都可以同意这些权限。其他应用程序需要管理员级权限，组织中的用户无法同意该权限。只有目录管理员才能同意需要此级别的权限的应用程序。当用户或管理员同意时，这两个 Web API 都在其目录中注册。

当第一个应用程序使用其授权代码获取 JWT 访问令牌时，它还会收到 JWT 刷新令牌。访问令牌过期时，刷新令牌可用于重新对用户进行身份验证，而无需提示输入凭据。然后，此刷新令牌用于对用户进行身份验证，这会导致新的访问令牌和刷新令牌。