本机应用

本机应用是代表用户调用 Web API 的应用程序。 此方案基于公共客户端的 OAuth 2.0 授权代码授予类型构建，如 OAuth 2.0 规范的第 4.1 节中所述。 本机应用程序使用 OAuth 2.0 协议为用户获取访问令牌。 然后，此访问令牌在请求中发送到 Web API，该 API 授权用户并返回所需的资源。

图表

协议流

如果您正在使用 AD（Active Directory）身份验证库，它将为您处理下面所述的大多数协议详细信息，例如浏览器弹出窗口、令牌缓存和刷新令牌处理。

1. 使用浏览器弹出窗口，本机应用程序向 Azure AD 中的授权终结点发出请求。 此请求包括应用程序 ID 和本机应用程序的重定向 URI，如 Azure 门户所示，以及 Web API 的应用程序 ID URI。 如果用户尚未登录，系统会提示他们再次登录
2. Azure AD 对用户进行身份验证。 如果它是多租户应用程序，并且需要使用该应用程序的同意，则用户需要同意（如果尚未这样做）。 授予许可并成功进行身份验证后，Azure AD 会向客户端应用程序的重定向 URI 发出授权代码响应。
3. 当 Azure AD 向重定向 URI 发出授权代码响应时，客户端应用程序会停止浏览器交互并从响应中提取授权代码。 使用此授权代码，客户端应用程序将请求发送到 Azure AD 的令牌终结点，其中包括授权代码、有关客户端应用程序的详细信息（应用程序 ID 和重定向 URI），以及所需的资源（Web API 的应用程序 ID URI）。
4. Azure AD 验证有关客户端应用程序和 Web API 的授权代码和信息。 成功验证后，Azure AD 返回两个令牌：JWT 访问令牌和 JWT 刷新令牌。 此外，Azure AD 还会返回有关用户的基本信息，例如用户的显示名称和租户 ID。
5. 通过 HTTPS，客户端应用程序使用返回的 JWT 访问令牌，在请求中以 "Bearer" 形式将 JWT 字符串加入到请求的授权标头中，从而访问 Web API。 然后，Web API 会验证 JWT 令牌，如果验证成功，则返回所需的资源。
6. 访问令牌过期时，客户端应用程序将收到一个错误，指示用户需要再次进行身份验证。 如果应用程序具有有效的刷新令牌，则可以使用它来获取新的访问令牌，而无需提示用户再次登录。 如果刷新令牌过期，应用程序需要再次以交互方式对用户进行身份验证。

代码示例

请参阅本机应用程序到 Web API 方案的代码示例。 我们会定期更新，请经常回来查看——我们也会经常添加新示例。 本地应用程序对接 Web API。

应用注册

若要向 Azure AD v1.0 终结点注册应用程序，请参阅 “注册应用”。

• 单租户 - 本机应用程序和 Web API 都必须在 Azure AD 中的同一目录中注册。 Web API 可配置为公开一组权限，这些权限用于限制本机应用程序对其资源的访问。 然后，客户端应用程序从 Azure 门户中的“对其他应用程序的权限”下拉菜单中选择所需的权限。
• 多租户 - 首先，该原生应用程序仅在开发者或发布商的目录中进行注册。 其次，原生应用程序被配置为展示其正常运行所需的权限。 当目标目录中的用户或管理员向应用程序提供许可时，对话框会显示此所需权限列表，使应用程序可供其组织使用。 某些应用程序只需要用户级权限，组织中的任何用户都可以同意这些权限。 其他应用程序需要管理员级权限，组织中的用户无法同意该权限。 只有目录管理员才能同意需要此级别的权限的应用程序。 当用户或管理员同意时，只会在其目录中注册 Web API。

令牌过期

当本机应用程序使用其授权代码获取 JWT 访问令牌时，它还会收到 JWT 刷新令牌。 访问令牌过期时，刷新令牌可用于重新对用户进行身份验证，而无需他们再次登录。 然后，此刷新令牌用于对用户进行身份验证，这会导致新的访问令牌和刷新令牌。

后续步骤

• 详细了解其他 应用程序类型和方案
• 了解 Azure AD 身份验证基础知识