Conexiones de OAuth 2.0 en el administrador de credenciales: flujos y detalles de procesos
SE APLICA A: todos los niveles de API Management
En este artículo se proporcionan detalles sobre los flujos de procesos para administrar las conexiones de OAuth 2.0 mediante el administrador de credenciales en Azure API Management. Los flujos de procesos se dividen en dos partes: administración y tiempo de ejecución.
Para obtener información general sobre el administrador de credenciales en API Management, consulte Acerca del administrador de credenciales y las credenciales de API en API Management.
Administración de conexiones
La parte de administración de las conexiones en el 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 y la configuración de una o varias conexiones con el proveedor de credenciales para acceder a estas.
La imagen siguiente resume el flujo de procesos para crear una conexión en API Management que usa el tipo de concesión de código de autorización.
Paso | Description |
---|---|
1 | El cliente envía una solicitud para crear un proveedor de credenciales. |
2 | Se crea el proveedor de credenciales y se devuelve una respuesta. |
3 | El cliente envía una solicitud para crear una conexión. |
4 | Se crea la conexión y se devuelve una respuesta con la información de que la conexión no está "conectada". |
5 | El cliente envía una solicitud para recuperar una dirección URL de inicio de sesión para iniciar el consentimiento de OAuth 2.0 en el proveedor de credenciales. La solicitud incluye una dirección URL posterior al redireccionamiento que se usará en el último paso |
6 | Se devuelve la respuesta con una dirección URL de inicio de sesión que se debe usar para iniciar el flujo de consentimiento. |
7 | El cliente abre un explorador con la dirección URL de inicio de sesión que se proporcionó en el paso anterior. El explorador se redirige al flujo de consentimiento de OAuth 2.0 del proveedor de credenciales. |
8 | Una vez aprobado el consentimiento, el explorador se redirige con un código de autorización a la dirección URL de redireccionamiento configurada en el proveedor de credenciales. |
9 | API Management usa el código de autorización para capturar los tokens de acceso y de actualización |
10 | API Management recibe los tokens y los cifra |
11 | API Management redirige a la dirección URL proporcionada en el paso 5 |
Proveedor de credenciales
Al configurar el proveedor de credenciales, puede elegir entre distintos proveedores de OAuth y tipos de concesión (código de autorización o credencial de cliente). Cada proveedor requiere configuraciones específicas. Importante a tener en cuenta:
- Una configuración de proveedor de credenciales solo puede tener un tipo de concesión.
- Una configuración de proveedor de credenciales puede tener múltiples conexiones.
Nota:
Con el proveedor Generic OAuth 2.0, se pueden usar otros proveedores de identidades que admitan los estándares del flujo de OAuth 2.0.
Al configurar un proveedor de credenciales, el administrador de credenciales crea, en segundo plano, un almacén de credenciales que se usa para almacenar en caché los tokens de actualización y los tokens de acceso de OAuth 2.0 del proveedor.
Conexión a un proveedor de credenciales
Para acceder a los tokens de un proveedor y usarlos, las aplicaciones cliente necesitan una conexión con el proveedor de credenciales. Las directivas de acceso permiten una conexión determinada en función de las identidades de Microsoft Entra ID. Puede configurar múltiples conexiones para un proveedor.
El proceso de configuración de una conexión difiere en función de la concesión configurada y es específico de la configuración del proveedor de credenciales. Por ejemplo, si quiere configurar Microsoft Entra ID para usar ambos tipos de concesión, se necesitan dos configuraciones de proveedor de credenciales. En la tabla siguiente se resumen los dos tipos de concesión.
Tipo de concesión | Descripción |
---|---|
Código de autorización | Vinculada a un contexto de usuario, lo que significa que un usuario debe dar su consentimiento a la conexión. Siempre y cuando que el token de actualización sea válido, API Management puede recuperar nuevos tokens de acceso y actualización. Si el token de actualización deja de ser válido, el usuario debe volver a realizar la autorización. Todos los proveedores de credenciales admiten el código de autorización. Más información |
Credenciales de cliente | No está vinculada a un usuario y se usa a menudo en escenarios de aplicación a aplicación. No se requiere ningún consentimiento para el tipo de concesión de credenciales de cliente y la conexión sigue siendo válida. Más información |
Consentimiento
Para las conexiones basadas en el tipo de concesión de código de autorización, debe autenticarse en el proveedor y dar su consentimiento a la autorización. Después del inicio de sesión y la autorización satisfactorios por parte del proveedor de credenciales, el proveedor devuelve tokens de acceso y actualización válidos, que son cifrados y guardados por API Management.
Directiva de acceso
Se configuran una o varias directivas de acceso para cada conexión. Las directivas de acceso determinan qué identidades de Microsoft Entra ID pueden obtener acceso a sus credenciales en tiempo de ejecución. Actualmente, las conexiones admiten el acceso mediante entidades de servicio, la identidad, los usuarios y los grupos de su instancia de API Management.
identidad | Descripción | Ventajas | Consideraciones |
---|---|---|---|
Entidad de servicio | Cuando una organización usa Microsoft Entra ID, las identidades cuyos tokens se pueden usar para autenticar y conceder acceso a recursos específicos de Azure. Al usar una entidad de servicio, las organizaciones evitan crear usuarios ficticios para gestionar la autenticación cuando necesitan acceder a un recurso. Una entidad de seguridad de servicio es una identidad de Microsoft Entra que representa una aplicación registrada de Microsoft Entra. | Permite un acceso más restringido a los escenarios de delegación de usuarios y conexión. No está vinculada a una instancia de API Management específica. Se basa en Microsoft Entra ID para la aplicación de permisos. | Para obtener el contexto de autorización se requiere un token de Microsoft Entra ID. |
Identidad administrada <Your API Management instance name> |
Esta opción corresponde a una identidad administrada vinculada a su instancia de API Management. | De forma predeterminada, se proporciona acceso a la identidad administrada asignada por el sistema para la instancia de API Management correspondiente. | La identidad está vinculada a la instancia de API Management. Cualquier persona con acceso de colaborador a la instancia de API Management puede acceder a cualquier conexión que conceda permisos de identidad administrada. |
Usuarios o grupos | Usuarios o grupos en el inquilino de Microsoft Entra ID. | Permite limitar el acceso a usuarios o grupos de usuarios específicos. | Requiere que los usuarios tengan una cuenta de Microsoft Entra ID. |
Tiempo de ejecución de las conexiones
La parte de tiempo de ejecución requiere que se configure una API OAuth 2.0 API de back-end con la directiva get-authorization-context
. En tiempo de ejecución, la directiva captura y almacena los tokens de acceso y actualización del almacén de credenciales que API Management configuró para el proveedor. 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 credenciales. A continuación, el token de acceso se usa para autorizar el acceso al servicio back-end.
Durante la ejecución de la directiva, también se valida el acceso a los tokens mediante directivas de acceso.
La siguiente imagen muestra un flujo de procesos de ejemplo para capturar y almacenar tokens de autorización y de actualización basados en una conexión que usa el tipo de concesión de código de autorización. Una vez recuperados los tokens, se realiza una llamada a la API de back-end.
Paso | Description |
---|---|
1 | El cliente envía la solicitud a la instancia de API Management |
2 | La directiva get-authorization-context comprueba si el token de acceso es válido para la conexión actual. |
3 | Si el token de acceso ha expirado pero el token de actualización es válido, API Management intenta capturar nuevos tokens de acceso y de actualización del proveedor de credenciales configurado. |
4 | El proveedor de credenciales devuelve un token de acceso y un token de actualización, que se cifran y guardan en API Management. |
5 | Una vez recuperados los tokens, el token de acceso se asocia mediante la directiva set-header como un encabezado de autorización a la solicitud saliente a la API de back-end |
6 | La respuesta se devuelve a API Management |
7 | La respuesta se devuelve al cliente |
Contenido relacionado
- Introducción al administrador de credenciales
- Configuración de proveedores de credenciales para el administrador de credenciales
- Configuración y uso de una conexión para Microsoft Graph API o la API de GitHub
- Configurar múltiples conexiones de autorización para un proveedor
- Configuración de una conexión para acceso delegado por el usuario