Compartir a través de


Acerca de las credenciales de API y el administrador de credenciales

SE APLICA A: todos los niveles de API Management

Para ayudarle a administrar el acceso a las API de back-end, la instancia de API Management incluye un administrador de credenciales. Use el administrador de credenciales para administrar, almacenar y controlar el acceso a las credenciales de API desde la instancia de API Management.

Nota:

  • Actualmente, puede usar el administrador de credenciales para configurar y administrar conexiones (anteriormente llamadas autorizaciones) para las API de OAuth 2.0 de back-end.
  • No se han introducido cambios importantes en el administrador de credenciales. Los proveedores y las conexiones de credenciales de OAuth 2.0 usan las API de autorización y el proveedor de recursos existentes de API Management.

Nota:

Actualmente, esta característica no está disponible en las áreas de trabajo.

Conexiones administradas para las API de OAuth 2.0

Con el administrador de credenciales, puede simplificar considerablemente el proceso de autenticación y autorización de usuarios, grupos y entidades de servicio en uno o varios servicios back-end o SaaS que usan OAuth 2.0. Usando el administrador de credenciales del API Management, es posible configurar fácilmente OAuth 2.0, el consentimiento, adquirir tokens en un almacén de credenciales, almacenar tokens en caché y actualizar tokens sin escribir una sola línea de código. Use directivas de acceso para delegar la autenticación en la instancia, las entidades de servicio, los usuarios o los grupos de API Management. Para comprender mejor OAuth 2.0, consulte Flujo de código de autorización de OAuth 2.0 - Plataforma de identidad de Microsoft.

Esta característica permite exponer las API con o sin clave de suscripción, usar autorizaciones OAuth 2.0 para servicios back-end y reducir los costos de desarrollo en el aumento, la implementación y el mantenimiento de las funciones de seguridad con integraciones de servicios.

Diagrama del administrador de credenciales de API Management y proveedores de identidades de SaaS compatibles.

Casos de uso de ejemplo

Con la administración de conexiones de OAuth en API Management, los clientes pueden conectarse fácilmente a proveedores SaaS o servicios back-end que utilicen OAuth 2.0. Estos son algunos ejemplos:

  • Conectarse fácilmente a un back-end SaaS adjuntando el token de autorización almacenado y proxyando solicitudes.

  • Realizar solicitudes proxy a una aplicación web Azure App Service o a un servicio backend de Azure Functions mediante la vinculación del token de autorización, que posteriormente puede enviar solicitudes a un servicio backend SaaS aplicando lógica de transformación.

  • Solicitudes de proxy a los back-end de federación de GraphQL mediante la asociación de varios tokens de acceso para realizar fácilmente la federación

  • Exponer un punto de conexión de token de recuperación, adquiera un token almacenado en caché y llame a un back-end de SaaS en nombre del usuario desde cualquier proceso, por ejemplo, una aplicación de consola o un demonio de Kubernetes. Combinar su SDK de SaaS favorito en un idioma compatible.

  • Azure Functions escenarios desatendidos cuando se conecta a múltiples back-end SaaS.

  • Durable Functions se acerca un paso más a Logic Apps con conectividad SaaS.

  • Con las conexiones OAuth 2.0, cada API de API Management puede actuar como un conector personalizado de Logic Apps.

¿Cómo funciona el administrador de credenciales?

Las credenciales de token en el administrador de credenciales constan de dos partes: gestión y runtime.

  • La parte de administración del administrador de credenciales se encarga de configurar y establecer un proveedor de credenciales para los tokens de OAuth 2.0, con la habilitación del flujo de consentimiento del proveedor de identidades y la configuración de una o varias conexiones con el proveedor de credenciales para acceder a estas. Para conocer más detalles, consulte Administración de conexiones.

  • La parte runtime usa la directiva get-authorization-context para obtener y almacenar los tokens de acceso y actualización de la conexión. Cuando entra una llamada en API Management y se ejecuta la directiva get-authorization-context, primero se valida si el token de autorización existente es válido. Si el token de autorización está caducado, API Management usa un flujo OAuth 2.0 para actualizar los tokens almacenados desde el proveedor de identidad. A continuación, el token de acceso se usa para autorizar el acceso al servicio back-end. Para conocer más detalles, consulte Runtime de conexiones.

¿Cuándo usar el administrador de credenciales?

A continuación se muestran tres casos para usar el administrador de credenciales.

Escenario de configuración

Después de configurar el proveedor de credenciales y una conexión, el administrador de API puede probar la conexión. El administrador de API configura una API de OAuth de back-end de prueba para usar la directiva de get-authorization-context mediante la identidad administrada de la instancia. Después, el administrador de API puede probar la conexión llamando a la API de prueba.

Diagrama del escenario de configuración inicial para el administrador de credenciales.

Escenario desatendido

De manera predeterminada, cuando se crea una conexión, se preconfigura una directiva de acceso y una conexión para la identidad administrada de la instancia de API Management. Para usar esta conexión, diferentes usuarios pueden iniciar sesión en una aplicación cliente, como una aplicación web estática, que luego llama a una API de back-end expuesta a través de API Management. Para hacer esta llamada, las conexiones se aplican mediante la directiva get-authorization-context. Dado que la llamada API usa una conexión preconfigurada que no está relacionada con el contexto del usuario, se devuelven los mismos datos a todos los usuarios.

Diagrama del escenario de identidad administrada para el administrador de credenciales.

Escenario asistido (delegado de usuario)

Para habilitar una experiencia de autenticación simplificada para los usuarios de aplicaciones cliente, como las aplicaciones web estáticas, que llaman a las API SaaS de back-end que requieren un contexto de usuario, puede habilitar el acceso a una conexión en nombre de una identidad de grupo o usuario de Microsoft Entra. En este caso, un usuario configurado debe iniciar sesión y proporcionar consentimiento solo una vez, y la instancia de API Management creará y administrará su conexión después de eso. Cuando API Management obtiene una llamada entrante que se reenvía a un servicio externo, adjunta el token de acceso de la conexión a la solicitud. Esto es ideal para cuando las solicitudes de API y las respuestas están orientadas a una persona (por ejemplo, recuperar información de perfil específica del usuario).

Diagrama del escenario delegado por el usuario para el administrador de credenciales.

¿Cómo controlar el administrador de credenciales?

Requisitos

  • La identidad asignada por el sistema administrada debe estar habilitada para la instancia de API Management.

  • La instancia de API Management debe tener conectividad saliente a Internet en el puerto 443 (HTTPS).

Disponibilidad

  • Todos los niveles de servicio de API Management

  • No se admite en la puerta de enlace autohospedada.

  • No se admite en nubes soberanas ni en las siguientes regiones: australiacentral, australiacentral2, indiacentral

Ejemplos paso a paso

Consideraciones sobre la seguridad

El token de acceso y otros secretos (por ejemplo, los secretos de cliente) se cifran con un cifrado de sobre y se almacenan en un sistema multiinquilino interno. Los datos se cifran con AES-128 mediante una clave única por dato. Esas claves se cifran asimétricamente con un certificado maestro almacenado en Azure Key Vault y se rotan cada mes.

Límites

Resource Límite
Número máximo de proveedores de credenciales por instancia de servicio 1,000
Número máximo de conexiones por proveedor de credenciales 10 000
Número máximo de directivas de acceso por conexión 100
Número máximo de solicitudes de autorización por minuto por conexión 250

Preguntas más frecuentes

¿Cuándo se actualizan los tokens de acceso?

Para una conexión de tipo código de autorización, los tokens de acceso se actualizan de la siguiente manera: Cuando se ejecuta la política get-authorization-context en tiempo de ejecución, API Management comprueba si el token de acceso almacenado es válido. Si el token ha expirado o está a punto de hacerlo, API Management usa el token de actualización para capturar un nuevo token de acceso y un nuevo token de actualización del proveedor de identidades configurado. Si el token de actualización ha expirado, se produce un error y la conexión debe volver a realizarse para que funcione.

¿Qué ocurre si el secreto de cliente expira en el proveedor de identidades?

En tiempo de ejecución, API Management no puede obtener nuevos tokens y se produce un error.

  • Si la conexión es de tipo código de autorización, el secreto de cliente debe actualizarse en el nivel de proveedor de conexión.

  • Si la conexión es de tipo credenciales de cliente, el secreto de cliente debe actualizarse en el nivel de conexiones.

¿Se admite esta característica cuando API Management se ejecuta dentro de una red virtual?

Sí, siempre que la conectividad saliente en el puerto 443 esté habilitada para la etiqueta de servicio AzureConnectors. Para obtener más información, consulte Referencia de configuración de Virtual Network.

¿Qué ocurre cuando se elimina un proveedor de conexiones?

También se eliminan todas las conexiones y directivas de acceso subyacentes.

¿API Management almacena en caché los tokens de acceso?

En los niveles de servicio clásico y v2, la instancia de API Management almacena en caché el token de acceso hasta 3 minutos antes de que expire el token. Si el token de acceso expira en menos de 3 minutos, el tiempo almacenado en caché será hasta que expire el token de acceso.

Los tokens de acceso no se almacenan en caché en el nivel Consumo.