Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
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. Con el administrador de credenciales de API Management, puede configurar fácilmente OAuth 2.0, gestionar el consentimiento, obtener tokens, almacenarlos en caché en un almacén de credenciales y actualizarlos, todo 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 una clave de suscripción mediante autorizaciones de OAuth 2.0 para los servicios back-end y reducir los costos de desarrollo al aumentar, implementar y mantener características de seguridad con integraciones de servicio.
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:
Conéctese fácilmente a un back-end de SaaS adjuntando el token de autorización almacenado y utilizando un proxy para las 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-ends de federación de GraphQL mediante la incorporación de varios tokens de acceso para facilitar la federación de manera sencilla.
Exponer un punto de conexión de token de recuperación, adquirir un token almacenado en caché y llamar a un backend 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 configurar un proveedor de credenciales para tokens de OAuth 2.0, lo que permite el flujo de consentimiento para el proveedor de identidades y configura una o varias conexiones con el proveedor de credenciales para acceder a las credenciales. Para conocer más detalles, consulte Administración de conexiones.
La parte runtime usa la directiva
get-authorization-contextpara obtener y almacenar los tokens de acceso y actualización de la conexión. Cuando una llamada entra en API Management y se ejecuta laget-authorization-contextdirectiva, 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?
Estos son tres escenarios 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.
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, distintos 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.
Escenario asistido (delegado por el usuario)
Para habilitar una experiencia de autenticación simplificada para los usuarios de aplicaciones cliente (como 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).
¿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
- Configuración del administrador de credenciales: GitHub API
- Configuración del administrador de credenciales: Microsoft Graph API
- Configuración del administrador de credenciales: acceso delegado de usuario a la API de back-end
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 datos. Esas claves se cifran asimétricamente con un certificado maestro almacenado en Azure Key Vault y se rotan cada mes.
Límites
| Recurso | 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 la get-authorization-context directiva se ejecuta 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 capturar 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 credenciales.
Si la conexión es de tipo credenciales de cliente, el secreto de cliente debe actualizarse en el nivel de conexión.
¿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ásicos y v2, la instancia de API Management almacena en caché el token de acceso hasta tres minutos antes de la hora de expiración del token. Si el token de acceso está a menos de tres minutos de expiración, 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.
Contenido relacionado
- Configuración de proveedores de credenciales para conexiones
- Configuración y uso de una conexión para Microsoft Graph API o la API de GitHub
- Configuración de una conexión para acceso delegado por el usuario
- Configure múltiples conexiones para un proveedor de credenciales