本机应用
警告
本内容适用于较旧版本的 Azure AD v1.0 终结点。 为新项目使用 Microsoft 标识平台。
本机应用是代表用户调用 Web API 的应用程序。 此方案是基于带有公共客户端的 OAuth 2.0 授权代码授予类型构建的，如 OAuth 2.0 规范的第 4.1 部分所述。 本机应用程序使用 OAuth 2.0 协议获取用户的访问令牌。 然后会在请求中将此访问令牌发送到 Web API，后者对用户进行授权并返回所需的资源。
图示
协议流
如果使用 AD 身份验证库，它会替你处理下面所述的大多数协议细节，例如浏览器弹出窗口、令牌缓存以及对刷新令牌的处理。
- 本机应用程序使用浏览器弹出窗口向 Azure AD 中的授权终结点发出请求。 此请求包括本机应用程序的应用程序 ID 和重定向 URI（如 Azure 门户中所示），以及 Web API 的应用程序 ID URI。 如果用户尚未登录，系统会再次提示他们登录
- Azure AD 对用户进行身份验证。 如果它是一个多租户应用程序并且需要许可才能使用应用程序，则用户需要表示许可（如果他们尚未如此做）。 在用户授予许可并成功进行身份验证后，Azure AD 会将一个授权代码响应发回客户端应用程序的重定向 URI。
- Azure AD 将授权代码响应发回重定向 URI 时，客户端应用程序将停止浏览器交互并从响应中提取授权代码。 使用此授权代码，客户端应用程序向 Azure AD 的令牌终结点发送请求，请求中包括授权代码、关于客户端应用程序的详细信息（应用程序 ID 和重定向 URI）以及所需的资源（Web API 的应用程序 ID URI）。
- Azure AD 对授权代码和关于客户端应用程序和 Web API 的信息进行验证。 验证成功时，Azure AD 返回两个令牌：一个 JWT 访问令牌和一个 JWT 刷新令牌。 此外，Azure AD 还会返回关于用户的基本信息，例如其显示名称和租户 ID。
- 通过 HTTPS，客户端应用程序使用返回的 JWT 访问令牌在发往 Web API 的请求的 Authorization 标头中添加一个具有“Bearer”限定符的 JWT 字符串。 然后，Web API 对 JWT 令牌进行验证，如果验证成功，则返回所需的资源。
- 访问令牌过期时，客户端应用程序会收到一个错误，指出用户需要重新进行身份验证。 如果应用程序具有有效的刷新令牌，可以使用它来获取新的访问令牌，系统不会提示用户重新登录。 如果刷新令牌过期，应用程序会再次需要以交互方式对用户进行身份验证。
注意
Azure AD 颁发的刷新令牌可以用来访问多个资源。 例如，如果某个客户端应用程序有权调用两个 Web API，则同样可以使用刷新令牌来获取其他 Web API 的访问令牌。
代码示例
请参阅本机应用程序到 Web API 方案的代码示例。 另外，请经常回来查看 - 我们会经常添加新示例。 本机应用程序到 Web API。
应用注册
若要向 Azure AD v1.0 终结点注册应用程序，请参阅注册应用。
- 单租户 - 本机应用程序和 Web API 必须在 Azure AD 的同一个目录中进行注册。 可以对 Web API 进行配置以公开一组权限，并使用这些权限来限制本机应用程序对其资源的访问。 然后，客户端应用程序从 Azure 门户的“对其他应用程序的权限”下拉菜单中选择所需的权限。
- 多租户 - 首先，本机应用程序只在开发人员或发布者的目录中注册过。 其次，本机应用程序在配置后会指示它在正常运行时所需的权限。 目标目录中的用户或管理员许可应用程序的要求，使应用程序可供其组织使用时，此必需权限列表会显示在一个对话框中。 某些应用程序只需要用户级权限，组织中的任何用户都可以表示许可。 另外一些应用程序需要管理员级权限，组织中的用户无法许可。 只有目录管理员可以对需要此级别的权限的应用程序表示许可。 当用户或管理员许可后，才会在其目录中注册该 Web API。
令牌过期
本机应用程序使用其授权代码来获取 JWT 访问令牌时，它还会收到一个 JWT 刷新令牌。 访问令牌过期时，可以使用刷新令牌来重新对用户进行身份验证，不需要他们重新登录。 然后将使用此刷新令牌对用户进行身份验证，生成新的访问令牌和刷新令牌。