方案:用于调用 Web API 的守护程序应用程序Scenario: Daemon application that calls web APIs

了解在构建用于调用 Web API 的守护程序应用程序时需要的所有项目。Learn all you need to build a daemon application that calls web APIs.


应用程序可以获取一个令牌,代表自身(而不是用户)调用 Web API。Your application can acquire a token to call a web API on behalf of itself (not on behalf of a user). 此方案适用于守护程序应用程序。This scenario is useful for daemon applications. 它使用标准 OAuth 2.0 客户端凭据授予。It uses the standard OAuth 2.0 client credentials grant.


下面是介绍守护程序应用用例的一些例子:Here are some examples of use cases for daemon apps:

  • 用于预配或管理用户,或者在目录中执行批处理的 Web 应用程序Web applications that are used to provision or administer users or do batch processes in a directory
  • 执行批处理作业的桌面应用程序(例如 Windows 上的 Windows 服务,或 Linux 上的守护程序进程),或者在后台运行的操作系统服务Desktop applications (like Windows services on Windows or daemon processes on Linux) that perform batch jobs, or an operating system service that runs in the background
  • 需操作目录而非特定用户的 Web APIWeb APIs that need to manipulate directories, not specific users

非守护程序应用程序使用客户端凭据的另一种常见情况是:即使它们代表用户进行操作,出于技术原因,它们也需要以自己的标识访问 Web API 或资源。There's another common case where non-daemon applications use client credentials: even when they act on behalf of users, they need to access a web API or a resource under their own identity for technical reasons. 例如,访问 Azure Key Vault 或用于缓存的 Azure SQL 数据库中的机密。An example is access to secrets in Azure Key Vault or Azure SQL Database for a cache.

获取其自身标识的令牌的应用程序具有以下特点:Applications that acquire a token for their own identities:

  • 是机密客户端应用程序。Are confidential client applications. 这些应用是以独立方式访问用户的资源,因此需证明其身份。These apps, given that they access resources independently of users, need to prove their identity. 它们也是相当敏感的应用。They're also rather sensitive apps. 它们需要获得 Azure Active Directory (Azure AD) 租户管理员的批准。They need to be approved by the Azure Active Directory (Azure AD) tenant admins.
  • 已将机密(应用程序密码或证书)注册到 Azure AD。Have registered a secret (application password or certificate) with Azure AD. 该机密是在调用 Azure AD 以获取令牌的过程中传入的。This secret is passed in during the call to Azure AD to get a token.



  • 用户无法与守护程序应用程序进行交互。Users can't interact with a daemon application. 守护程序应用程序需要其自己的标识A daemon application requires its own identity. 此类型的应用程序通过以下方式来请求访问令牌:使用其应用程序标识并向 Azure AD 提供其应用程序 ID、凭据(密码或证书)以及应用程序 ID URI。This type of application requests an access token by using its application identity and presenting its application ID, credential (password or certificate), and application ID URI to Azure AD. 在身份验证成功后,守护程序应用程序会从 Microsoft 标识平台终结点收到一个访问令牌(和一个刷新令牌)。After successful authentication, the daemon receives an access token (and a refresh token) from the Microsoft identity platform endpoint. 然后,将使用该令牌来调用 Web API(将会根据需要刷新该令牌)。This token is then used to call the web API (and is refreshed as needed).
  • 由于用户无法与守护程序应用程序进行交互,因此无法进行增量许可。Because users can't interact with daemon applications, incremental consent isn't possible. 所有必需的 API 权限都需要在注册应用程序时配置。All the required API permissions need to be configured at application registration. 应用程序的代码只请求静态定义的权限。The code of the application just requests statically defined permissions. 这也意味着守护程序应用程序不会支持增量许可。This also means that daemon applications won't support incremental consent.

对于开发人员来说,此方案的端到端体验具有以下特点:For developers, the end-to-end experience for this scenario has the following aspects:

  • 守护程序应用程序只能在 Azure AD 租户中工作。Daemon applications can work only in Azure AD tenants. 如果你是业务线 (LOB) 应用开发人员,则需在租户中创建守护程序应用。If you're a line-of-business (LOB) app developer, you'll create your daemon app in your tenant. 如果你是 ISV,你可能希望创建多租户守护程序应用程序,If you're an ISV, you might want to create a multitenant daemon application. 每个租户管理员都需要提供许可。Each tenant admin will need to provide consent.
  • 注册应用程序期间,回复 URI 不是必需的。During application registration, the reply URI isn't needed. 你需要与 Azure AD 共享机密或证书或已签名断言。You need to share secrets or certificates or signed assertions with Azure AD. 你还需要请求应用程序权限,并授予管理员许可才能使用这些应用权限。You also need to request application permissions and grant admin consent to use those app permissions.
  • 应用程序配置需要提供客户端凭据,这些凭据是在应用程序注册期间与 Azure AD 共享的。The application configuration needs to provide client credentials as shared with Azure AD during the application registration.
  • 用于通过客户端凭据流获取令牌的作用域必须是静态作用域。The scope used to acquire a token with the client credentials flow needs to be a static scope.

如果你不熟悉 OAuth 2.0 和 OpenID Connect 的标识和访问管理 (IAM),甚至不熟悉 Microsoft 标识平台上的 IAM,请将下列文章加入你的阅读列表。If you're new to identity and access management (IAM) with OAuth 2.0 and OpenID Connect, or even just new to IAM on the Microsoft identity platform, the following set of articles should be high on your reading list.

虽然在完成第一个快速入门或教程之前不需要阅读这些文章,但是它们涵盖了平台不可或缺的主题,熟悉它们将有助于构建更复杂的方案。Although not required reading before completing your first quickstart or tutorial, they cover topics integral to the platform, and familiarity with them will help you on your path as you build more complex scenarios.

后续步骤Next steps

转到此方案中的下一篇文章:应用注册Move on to the next article in this scenario, App registration.