[Azure API Management]关于API凭据和凭据管理器

To help you manage access to backend APIs, your API Management instance includes a credential manager. Use credential manager to manage, store, and control access to API credentials from your API Management instance.

Using credential manager, you can greatly simplify the process of authenticating and authorizing users, groups, and service principals across one or more backend or SaaS services that use OAuth 2.0. Using API Management's credential manager, easily configure OAuth 2.0, consent, acquire tokens, cache tokens in a credential store, and refresh tokens without writing a single line of code. Use access policies to delegate authentication to your API Management instance, service principals, users, or groups. For background about the OAuth 2.0, see Microsoft identity platform and OAuth 2.0 authorization code flow.

This feature enables APIs to be exposed with or without a subscription key, use OAuth 2.0 authorizations for backend services, and reduce development costs in ramping up, implementing, and maintaining security features with service integrations.

Using OAuth connections managed in API Management, customers can easily connect to SaaS providers or backend services that are using OAuth 2.0. Here are some examples:

• Easily connect to a SaaS backend by attaching the stored authorization token and proxying requests

• Proxy requests to an Azure App Service web app or Azure Functions backend by attaching the authorization token, which can later send requests to a SaaS backend applying transformation logic

• Proxy requests to GraphQL federation backends by attaching multiple access tokens to easily perform federation

• Expose a retrieve token endpoint, acquire a cached token, and call a SaaS backend on behalf of user from any compute, for example, a console app or Kubernetes daemon. Combine your favorite SaaS SDK in a supported language.

• Azure Functions unattended scenarios when connecting to multiple SaaS backends.

• Durable Functions gets a step closer to Logic Apps with SaaS connectivity.

• With OAuth 2.0 connections, every API in API Management can act as a Logic Apps custom connector.

Token credentials in credential manager consist of two parts: management and runtime.

• The management part in credential manager takes care of setting up and configuring a credential provider for OAuth 2.0 tokens, enabling the consent flow for the identity provider, and setting up one or more connections to the credential provider for access to the credentials. For details, see Management of connections.

• The runtime part uses the get-authorization-context policy to fetch and store the connection's access and refresh tokens. When a call comes into API Management, and the get-authorization-context policy is executed, it first validates if the existing authorization token is valid. If the authorization token has expired, API Management uses an OAuth 2.0 flow to refresh the stored tokens from the identity provider. Then the access token is used to authorize access to the backend service. For details, see Runtime of connections.

The following are three scenarios for using credential manager.

After configuring the credential provider and a connection, the API manager can test the connection. The API manager configures a test backend OAuth API to use the get-authorization-context policy using the instance's managed identity. The API manager can then test the connection by calling the test API.

By default when a connection is created, an access policy and connection are preconfigured for the managed identity of the API Management instance. To use such a connection, different users may sign in to a client application such as a static web app, which then calls a backend API exposed through API Management. To make this call, connections are applied using the get-authorization-context policy. Because the API call uses a preconfigured connection that's not related to the user context, the same data is returned to all users.

To enable a simplified authentication experience for users of client applications, such as static web apps, that call backend SaaS APIs that require a user context, you can enable access to a connection on behalf of a Microsoft Entra user or group identity. In this case, a configured user needs to login and provide consent only once, and the API Management instance will create and manage their connection after that. When API Management gets an incoming call to be forwarded to an external service, it attaches the access token from the connection to the request. This is ideal for when API requests and responses are geared towards an individual (for example, retrieving user-specific profile information).

• Managed system-assigned identity must be enabled for the API Management instance.

• API Management instance must have outbound connectivity to internet on port 443 (HTTPS).

• All API Management service tiers

• Not supported in self-hosted gateway

• Not supported in sovereign clouds or in the following regions: australiacentral, australiacentral2, indiacentral

• Configure credential manager - GitHub API
• Configure credential manager - Microsoft Graph API
• Configure credential manager - user-delegated access

The access token and other secrets (for example, client secrets) are encrypted with an envelope encryption and stored in an internal, multitenant storage. The data are encrypted with AES-128 using a key that is unique per data. Those keys are encrypted asymmetrically with a master certificate stored in Azure Key Vault and rotated every month.

For a connection of type authorization code, access tokens are refreshed as follows: When the get-authorization-context policy is executed at runtime, API Management checks if the stored access token is valid. If the token has expired or is near expiry, API Management uses the refresh token to fetch a new access token and a new refresh token from the configured identity provider. If the refresh token has expired, an error is thrown, and the connection needs to be reauthorized before it will work.

At runtime API Management can't fetch new tokens, and an error occurs.

• If the connection is of type authorization code, the client secret needs to be updated on credential provider level.

• If the connection is of type client credentials, the client secret needs to be updated on the connection level.

Yes, as long as outbound connectivity on port 443 is enabled to the AzureConnectors service tag. For more information, see Virtual network configuration reference.

All underlying connections and access policies are also deleted.

In the classic and v2 service tiers, the access token is cached by the API Management instance until 3 minutes before the token expiration time. If the access token is less than 3 minutes away from expiration, the cached time will be until the access token expires.

Access tokens aren't cached in the Consumption tier.

• Configure credential providers for connections
• Configure and use a connection for the Microsoft Graph API or the GitHub API
• Configure a connection for user-delegated access
• Configure multiple connections for a credential provider