Compartir a través de

Autenticación y autorización para las API en Azure API Management

  • Artículo

SE APLICA A: todos los niveles de API Management

Este artículo es una introducción a un amplio conjunto flexible de características de API Management que le ayudan a proteger el acceso de los usuarios a las API administradas.

La autenticación y autorización de API en API Management implican asegurar la comunicación de un extremo a otro de las aplicaciones cliente a la puerta de enlace de API Management y a través de las API de back-end. En muchos entornos de cliente, OAuth 2.0 es el protocolo de autorización de API preferido. API Management admite la autorización de OAuth 2.0 entre el cliente y la puerta de enlace de API Management, entre la puerta de enlace y la API de back-end, o ambas de forma independiente.

Diagrama que muestra los puntos de interacción para asegurar las API.

API Management admite otros mecanismos de autenticación y autorización del lado cliente y del lado del servicio que complementan OAuth 2.0 o que son útiles cuando la autorización de OAuth 2.0 para las API no es posible. La forma de elegir entre estas opciones depende de la madurez del entorno de API de su organización, de los requisitos de seguridad y cumplimiento, y del enfoque de su organización para mitigar las amenazas comunes de API.

Importante

Proteger el acceso de los usuarios a las API es una de las muchas consideraciones para proteger el entorno de API Management. Para obtener más información, consulte Línea de base de seguridad de Azure para API Management.

Nota

Otros componentes de API Management tienen mecanismos independientes para proteger y restringir el acceso de los usuarios:

  • Para administrar la instancia de API Management a través del plano de control de Azure, API Management se basa en Microsoft Entra ID y el control de acceso basado en roles (RBAC) de Azure.
  • El portal para desarrolladores de API Management admite varias opciones para facilitar el registro y el inicio de sesión de usuarios seguros.

Autenticación frente a autorización

Esta es una breve explicación de la autenticación y autorización en el contexto del acceso a las API:

  • Autenticación: proceso de comprobación de la identidad de un usuario o aplicación que accede a la API. La autenticación se puede realizar mediante credenciales como el nombre de usuario y la contraseña, un certificado o a través del inicio de sesión único (SSO) u otros métodos.

  • Autorización: el proceso de determinar si un usuario o una aplicación tiene permiso para acceder a una API determinada, a menudo a través de un protocolo basado en tokens, como OAuth 2.0.

Nota

Para complementar la autenticación y la autorización, el acceso a las API también debe protegerse mediante TLS para proteger las credenciales o tokens que se usan para la autenticación o autorización.

Conceptos de OAuth 2.0

OAuth 2.0 es un marco de autorización estándar que se usa ampliamente para proteger el acceso a los recursos, como las API web. OAuth 2.0 restringe las acciones de lo que una aplicación cliente puede realizar en recursos en nombre del usuario, sin compartir nunca las credenciales del usuario. Aunque OAuth 2.0 no es un protocolo de autenticación, a menudo se usa con OpenID Connect (OIDC), que amplía OAuth 2.0 proporcionando autenticación de usuario y funcionalidad de inicio de sesión único.

Flujo de OAuth

¿Qué ocurre cuando una aplicación cliente llama a una API con una solicitud protegida mediante TLS y OAuth 2.0? A continuación se muestra un flujo de ejemplo abreviado:

  • El cliente (la aplicación que realiza la llamada o el portador) se autentica mediante credenciales en un proveedor de identidades.

  • El cliente obtiene un token de acceso limitado (un token web JSON o JWT) del servidor de autorización del proveedor de identidades.

    El proveedor de identidades (por ejemplo, Microsoft Entra ID) es el emisor del token y el token incluye una notificación de audiencia que autoriza el acceso a un servidor de recursos (por ejemplo, a una API de back-end o a la propia puerta de enlace de API Management).

  • El cliente llama a la API y presenta el token de acceso, por ejemplo, en un encabezado de autorización.

  • El servidor de recursos valida el token de acceso. La validación es un proceso complejo que incluye una comprobación de que las notificaciones de emisor y audiencia contienen valores esperados.

  • En función de los criterios de validación de tokens, se concede el acceso a los recursos de la API de back-end.

Según el tipo de aplicación cliente y los escenarios, se necesitan diferentes flujos de autorización para solicitar y administrar los tokens. Por ejemplo, el flujo de código de autorización y el tipo de concesión se usan normalmente en las aplicaciones que llaman a las API web. Obtenga más información sobre los flujos de OAuth y los escenarios de aplicación en Microsoft Entra ID.

Escenarios de autorización de OAuth 2.0 en API Management

Escenario 1: la aplicación cliente autoriza directamente al back-end

Un escenario de autorización común es cuando la aplicación que realiza la llamada solicita acceso a la API de back-end directamente y presenta un token de OAuth 2.0 en un encabezado de autorización a la puerta de enlace. Azure API Management actúa como un proxy "transparente" entre el autor de la llamada y la API de back-end y pasa el token sin cambios al back-end. El ámbito del token de acceso está entre la aplicación que realiza la llamada y la API de back-end.

En la imagen siguiente se muestra un ejemplo en el que Microsoft Entra ID es el proveedor de autorización. La aplicación cliente puede ser una aplicación de página única (SPA).

Diagrama en el que se muestra la comunicación de OAuth donde el público es el back-end.

Aunque el token de acceso enviado junto con la solicitud HTTP está pensado para la API de back-end, API Management sigue permitiendo un enfoque de defensa en profundidad. Por ejemplo, configure directivas para validar el JWT, y rechazar solicitudes que llegan sin un token, o un token que no sea válido para la API de back-end prevista. También puede configurar API Management para comprobar otras notificaciones de interés extraídas del token.

Nota:

Si protege una API expuesta a través de Azure API Management con OAuth 2.0 de esta manera, puede configurar API Management para generar un token válido con fines de prueba en nombre de un usuario de consola de prueba de Azure Portal o portal para desarrolladores. Debe agregar un servidor de OAuth 2.0 a la instancia de API Management y habilitar la configuración de autorización de OAuth 2.0 en la API. Para más información, vea Procedimiento para autorizar la consola de prueba del portal para desarrolladores mediante la configuración de la autorización de usuarios de OAuth 2.0.

Ejemplo:

Sugerencia

En el caso especial cuando el acceso a la API está protegido mediante Microsoft Entra ID, puede configurar la directiva validate-azure-ad-token para la validación de tokens.

Escenario 2: la aplicación cliente autoriza a API Management

En este escenario, el servicio API Management actúa en nombre de la API y la aplicación que realiza la llamada solicita acceso a la instancia de API Management. El ámbito del token de acceso está entre la aplicación que realiza la llamada y la puerta de enlace de API Management. En API Management, configure una directiva (validate-jwt o validate-azure-ad-token) para validar el token antes de que la puerta de enlace pase la solicitud al back-end. Normalmente, un mecanismo independiente protege la conexión entre la puerta de enlace y la API de back-end.

En el ejemplo siguiente, Microsoft Entra ID es de nuevo el proveedor de autorización y la autenticación TLS mutua (mTLS) protege la conexión entre la puerta de enlace y el back-end.

Diagrama en el que se muestra la comunicación de OAuth donde el público es la puerta de enlace de API Management.

Hay diferentes razones para hacer esto. Por ejemplo:

  • El back-end es una API heredada que no se puede actualizar para admitir OAuth

    API Management se debe configurar primero para validar el token (y comprobar las notificaciones de emisor y público como mínimo). Después de la validación, use una de las varias opciones disponibles para proteger las conexiones posteriores a partir de API Management, como la autenticación TLS mutua (mTLS). Vea Opciones del lado servicio más adelante en este artículo.

  • El contexto necesario para el back-end no se puede establecer desde el autor de la llamada

    Después de que API Management haya validado correctamente el token recibido del autor de la llamada, debe obtener un token de acceso para la API de back-end mediante su propio contexto, o bien un contexto derivado de la aplicación que realiza la llamada. Este escenario se puede realizar mediante:

    • Una directiva personalizada, como send-request, para obtener un token de acceso posterior válido para la API de back-end desde un proveedor de identidades configurado.

    • La propia identidad de la instancia de API Management, pasando el token desde la identidad administrada asignada por el sistema o por el usuario del recurso de API Management a la API de back-end.

  • La organización quiere adoptar un enfoque de autorización estandarizado

    Independientemente de los mecanismos de autenticación y autorización en sus API de back-end, las organizaciones pueden optar por converger en OAuth 2.0 para un enfoque de autorización estandarizado en el front-end. La puerta de enlace de API Management puede habilitar la configuración de autorización coherente y una experiencia común para los consumidores de API a medida que evolucionan los back-end de la organización.

Escenario 3: API Management autoriza al back-end

Con las conexiones administradas (que antes de denominaban autorizaciones), se usa el administrador de credenciales de API Management para autorizar el acceso a uno o varios servicios de back-end o SaaS, como LinkedIn, GitHub u otros back-end compatibles con OAuth 2.0. En este escenario, una aplicación cliente o usuario realiza una solicitud a la puerta de enlace de API Management, con acceso de puerta de enlace controlado mediante un proveedor de identidades u otras opciones del lado cliente. A continuación, mediante la configuración de directivas, el usuarios o la aplicación cliente delega la autenticación y autorización del back-end a API Management.

En el ejemplo siguiente, se usa una clave de suscripción entre el cliente y la puerta de enlace, y GitHub es el proveedor de credenciales de la API de back-end.

Diagrama en el que se muestra la autorización al servicio SaaS de back-end mediante una conexión administrada en el administrador de credenciales.

Con una conexión a un proveedor de credenciales, API Management adquiere y actualiza los tokens para el acceso a la API en el flujo de OAuth 2.0. Las conexiones simplifican la administración de tokens en varios escenarios, como:

  • Es posible que una aplicación cliente tenga que autorizar a varios back-end de SaaS para resolver varios campos mediante solucionadores de GraphQL.
  • Los usuarios se autentican en API Management mediante un inicio de sesión único desde su proveedor de identidades, pero autorizan a un proveedor SaaS de back-end (como LinkedIn) mediante una cuenta de organización común.
  • Una aplicación cliente (o bot) necesita acceder a los recursos en línea protegidos por back-end en nombre de un usuario autenticado (por ejemplo, comprobar correos electrónicos o realizar un pedido).

Ejemplos:

Otras opciones para proteger las API

Aunque se prefiere la autorización y OAuth 2.0 se ha convertido en el método dominante para habilitar la autorización sólida para las API, API Management proporciona varios mecanismos distintos para proteger o restringir el acceso entre el cliente y la puerta de enlace (lado cliente) o entre la puerta de enlace y el back-end (lado del servicio). En función de los requisitos de la organización, se pueden usar para complementar OAuth 2.0. Como alternativa, configúrelos de forma independiente si las aplicaciones que llaman o las API de back-end son heredadas o aún no admiten OAuth 2.0.

Opciones del lado cliente

Mechanism Descripción Consideraciones
mTLS Validar el certificado presentado por el cliente de conexión y comprobar las propiedades del certificado en un certificado administrado en API Management El certificado se puede almacenar en un almacén de claves.
Restringir IP de autor de llamada Filtrar (permitir o denegar) llamadas desde direcciones IP o intervalos de direcciones específicos. Se usa para restringir el acceso a determinados usuarios u organizaciones, o al tráfico de los servicios ascendentes.
Clave de suscripción Limitar el acceso a una o varias API en función de una suscripción de API Management Se recomienda usar una clave de suscripción (API) además de otro método de autenticación o autorización. Por sí sola, una clave de suscripción no es una forma segura de autenticación, pero el uso de la clave de suscripción podría ser útil en determinados escenarios, por ejemplo, el seguimiento del uso de la API de los clientes individuales o la concesión de acceso a productos de API específicos.

Sugerencia

Para la defensa en profundidad, se recomienda encarecidamente implementar un firewall de aplicaciones web ascendente de la instancia de API Management. Por ejemplo, use Azure Application Gateway o Azure Front Door.

Opciones del lado del servicio

Mechanism Descripción Consideraciones
Autenticación de identidad administrada Autentíquese en la API de back-end con una identidad administrada asignada por el sistema o asignada por el usuario. Se recomienda para el acceso con ámbito a un recurso de back-end protegido mediante la obtención de un token de Microsoft Entra ID.
Autenticación de certificado Autentíquese en la API de back-end mediante un certificado de cliente. El certificado se puede almacenar en el almacén de claves.
Autenticación básica Autentíquese en la API de back-end con el nombre de usuario y la contraseña que se pasan a través de un encabezado de autorización. No se recomienda si hay mejores opciones disponibles.

Pasos siguientes