跳转到主要内容

热门内容

今日:


总体:


最近浏览:


Chinese, Simplified

category

本文提供了有关在Azure API管理中使用凭据管理器管理OAuth 2.0连接的流程的详细信息。流程分为两部分:管理和运行时。

有关API管理中的凭据管理器的背景信息,请参阅API管理中的关于凭据管理器和API凭据。

连接管理


凭证管理器中连接的管理部分负责为OAuth 2.0令牌设置和配置凭证提供者,为提供者启用同意流,并设置一个或多个与凭证提供者的连接以访问凭证。

下图总结了在API管理中创建使用授权代码授予类型的连接的流程。

显示创建凭据的流程图。

步骤说明


 

Step Description
1 Client sends a request to create a credential provider
2 Credential provider is created, and a response is sent back
3 Client sends a request to create a connection
4 Connection is created, and a response is sent back with the information that the connection isn't "connected"
5 Client sends a request to retrieve a login URL to start the OAuth 2.0 consent at the credential provider. The request includes a post-redirect URL to be used in the last step
6 Response is returned with a login URL that should be used to start the consent flow.
7 Client opens a browser with the login URL that was provided in the previous step. The browser is redirected to the credential provider's OAuth 2.0 consent flow
8 After the consent is approved, the browser is redirected with an authorization code to the redirect URL configured at the credential provider
9 API Management uses the authorization code to fetch access and refresh tokens
10 API Management receives the tokens and encrypts them
11 API Management redirects to the provided URL from step 5

 

凭据提供程序


配置凭据提供程序时,您可以在不同的OAuth提供程序和授权类型(授权码或客户端凭据)之间进行选择。每个提供程序都需要特定的配置。需要牢记的重要事项:

  • 凭据提供程序配置只能有一种授权类型。
  • 一个凭据提供程序配置可以有多个连接。

笔记

使用通用OAuth 2.0提供程序,可以使用支持OAuth 2.0流标准的其他身份提供程序。

配置凭据提供程序时,后台凭据管理器会创建一个凭据存储,用于缓存提供程序的OAuth 2.0访问令牌和刷新令牌。

与凭据提供程序的连接


要访问和使用提供者的令牌,客户端应用程序需要连接到凭据提供者。基于Microsoft Entra ID标识的访问策略允许给定的连接。您可以为提供程序配置多个连接。

配置连接的过程因配置的授权而异,并且特定于凭证提供者配置。例如,如果要将Microsoft Entra ID配置为使用两种授权类型,则需要两种凭据提供程序配置。下表总结了两种补助金类型。

Grant type Description
Authorization code Bound to a user context, meaning a user needs to consent to the connection. As long as the refresh token is valid, API Management can retrieve new access and refresh tokens. If the refresh token becomes invalid, the user needs to reauthorize. All credential providers support authorization code. Learn more
Client credentials Isn't bound to a user and is often used in application-to-application scenarios. No consent is required for client credentials grant type, and the connection doesn't become invalid. Learn more


 

同意


对于基于授权码授权类型的连接,您必须向提供商进行身份验证并同意授权。凭证提供者成功登录并授权后,提供者返回有效的访问和刷新令牌,这些令牌由API管理加密并保存。

访问策略


您可以为每个连接配置一个或多个访问策略。访问策略决定了哪些Microsoft Entra ID身份可以在运行时访问您的凭据。连接当前支持使用服务主体、API管理实例的标识、用户和组进行访问。

Identity Description Benefits Considerations
Service principal Identity whose tokens can be used to authenticate and grant access to specific Azure resources, when an organization is using Microsoft Entra ID. By using a service principal, organizations avoid creating fictitious users to manage authentication when they need to access a resource. A service principal is a Microsoft Entra identity that represents a registered Microsoft Entra application. Permits more tightly scoped access to connection and user delegation scenarios. Isn't tied to specific API Management instance. Relies on Microsoft Entra ID for permission enforcement. Getting the authorization context requires a Microsoft Entra ID token.
Managed identity <Your API Management instance name> This option corresponds to a managed identity tied to your API Management instance. By default, access is provided to the system-assigned managed identity for the corresponding API management instance. Identity is tied to your API Management instance. Anyone with Contributor access to API Management instance can access any connection granting managed identity permissions.
Users or groups Users or groups in your Microsoft Entra ID tenant. Allows you to limit access to specific users or groups of users. Requires that users have a Microsoft Entra ID account.


 

连接运行时间


运行时部分需要使用get-authorization-context策略配置后端OAuth 2.0 API。在运行时,策略从API管理为提供程序设置的凭据存储中获取和存储访问和刷新令牌。当调用进入API管理并执行get-authorization-context策略时,它首先验证现有授权令牌是否有效。如果授权令牌已过期,API管理将使用OAuth 2.0流刷新凭据提供程序中存储的令牌。然后,访问令牌用于授权对后端服务的访问。

在策略执行期间,还使用访问策略验证对令牌的访问。

下图显示了一个示例流程,用于根据使用授权码授权类型的连接获取和存储授权和刷新令牌。在取回令牌之后,对后端API进行调用。

步骤说明

  1. 客户端向API管理实例发送请求
  2. 获取授权上下文策略检查访问令牌是否对当前连接有效
  3. 如果访问令牌已过期但刷新令牌有效,API管理会尝试从配置的凭据提供程序获取新的访问和刷新令牌
  4. 凭证提供者返回访问令牌和刷新令牌,它们经过加密并保存到API管理
  5. 取回令牌后,使用set-header策略将访问令牌作为授权头附加到后端API的传出请求
  6. 响应返回API管理层
  7. 响应返回给客户端


相关内容

本文地址
最后修改
星期五, 七月 12, 2024 - 21:02
Article