Compartir vía

Autenticación y autorización en Azure Container Apps

  • Artículo

Azure Container Apps proporciona características integradas de autenticación y autorización (a veces conocidas como "Easy Auth"), para proteger la aplicación de contenedor con entrada habilitada con una cantidad mínima de código o sin código.

Para más información sobre la autenticación y autorización, consulte las siguientes guías para elegir el proveedor.

¿Por qué usar la autenticación integrada?

No es necesario usar esta característica para la autenticación y autorización. Puede usar las características de seguridad agrupadas en el marco de trabajo web de su elección o puede escribir sus propias utilidades. Sin embargo, la implementación de una solución segura para la autenticación (que permite el inicio de sesión de los usuarios) y la autorización (que proporciona acceso a los datos seguros) puede suponer un esfuerzo considerable. Debe asegurarse de seguir los procedimientos recomendados y los estándares del sector, así como mantener la implementación actualizada.

La característica de autenticación integrada de Container Apps le ahorra tiempo y esfuerzo al proporcionar autenticación lista para su uso con proveedores de identidades federados. Estas características le permiten centrarse más tiempo en desarrollar la aplicación y menos tiempo en la creación de sistemas de seguridad.

Entre las ventajas se encuentran las siguientes:

  • Azure Container Apps proporciona acceso a diversos proveedores de autenticación integrados.
  • Las características de autenticación integradas no requieren ningún idioma, SDK, experiencia en seguridad ni ningún código en particular que tenga que escribir.
  • Se puede integrar con varios proveedores, como Microsoft Entra ID, Facebook, Google y Twitter.

Proveedores de identidades

Container Apps usa la identidad federada, en la cual un proveedor de identidades de terceros almacena las identidades de usuario y el flujo de autenticación para usted. De forma predeterminada, están disponibles los siguientes proveedores de identidades:

Proveedor Punto de conexión de inicio de sesión Guía de procedimientos
Plataforma de identidad de Microsoft /.auth/login/aad Plataforma de identidad de Microsoft
Facebook /.auth/login/facebook Facebook
GitHub /.auth/login/github GitHub
Google /.auth/login/google Google
Twitter /.auth/login/twitter Twitter
Nuevo proveedor de OpenID Connect /.auth/login/<providerName> OpenID Connect

Cuando usa uno de estos proveedores, el punto de conexión de inicio de sesión está disponible para la autenticación de los usuarios y para la validación de tokens de autenticación del proveedor. Se puede proporcionar a los usuarios cualquier número de estas opciones de inicio de proveedor.

Consideraciones sobre el uso de la autenticación integrada

Esta característica solo debe usarse con HTTPS. Asegúrese de que allowInsecure está deshabilitado en la configuración de entrada de la aplicación de contenedor.

Puede configurar la aplicación de contenedor para la autenticación con o sin restringir el acceso al contenido del sitio y a las API. Para restringir el acceso a las aplicaciones solo a los usuarios autenticados, establezca su opción Restringir acceso en Requerir autenticación. Para realizar la autenticación sin restringir el acceso, establezca su valor Restringir acceso en Permitir acceso no autenticado.

De manera predeterminada, cada aplicación de contenedor emite su propia cookie o token únicos para la autenticación. También puede proporcionar sus propias claves de firma y cifrado.

Arquitectura de características

El componente de middleware de autenticación y autorización es una característica de la plataforma que se ejecuta como contenedor sidecar en cada réplica de la aplicación. Cuando se habilita, la aplicación controla cada solicitud HTTP entrante después de pasar por la capa de seguridad.

Diagrama de arquitectura que muestra las solicitudes que intercepta un contenedor sidecar que interactúa con los proveedores de identidades antes de permitir el tráfico al sitio implementado

El middleware de plataforma controla varios aspectos de la aplicación:

  • Esta autentica usuarios y clientes con los proveedores de identidades especificados.
  • Administra la sesión autenticada
  • Inserta información de identidad en encabezados de solicitud HTTP.

El módulo de autenticación y autorización se ejecuta en un contenedor independiente, aislado del código de la aplicación. Como el contenedor de seguridad no se ejecuta en proceso, no es posible la integración directa con marcos de lenguaje específicos. Sin embargo, la información pertinente que necesita la aplicación se proporciona en los encabezados de solicitud, como se explica en este artículo.

Flujo de autenticación

El flujo de autenticación es el mismo para todos los proveedores, pero varía en función de si desea iniciar sesión con el SDK del proveedor:

  • Sin el SDK del proveedor (flujo dirigido por el servidor o flujo de servidor): la aplicación delega el inicio de sesión federado a Container Apps. La delegación suele ser el caso de las aplicaciones de explorador, que presenta la página de inicio de sesión del proveedor al usuario.

  • Con el SDK del proveedor (flujo dirigido por el cliente o flujo de cliente): la aplicación inicia manualmente la sesión del usuario al proveedor y luego envía el token de autenticación a Container Apps para la validación. Este enfoque es típico para las aplicaciones sin explorador que no presentan la página de inicio de sesión del proveedor al usuario. Un ejemplo es una aplicación móvil nativa que proporciona inicio de sesión a los usuarios con el SDK del proveedor.

Las llamadas desde una aplicación de explorador de confianza en Container Apps a otra REST API de Container Apps se pueden autenticar mediante el flujo dirigido por el servidor. Para obtener más información, consulte Personalización del inicio y cierre de sesión.

En la tabla, se muestran los pasos del flujo de autenticación.

Paso Sin el SDK del proveedor Con el SDK del proveedor
1. Inicio de sesión del usuario Redirige el cliente a /.auth/login/<PROVIDER>. El código de cliente proporciona inicio de sesión al usuario directamente con el SDK del proveedor y recibe un token de autenticación. Para información, consulte la documentación del proveedor.
2. Autenticación posterior El proveedor redirige el cliente a /.auth/login/<PROVIDER>/callback. El código de cliente publica el token del proveedor en /.auth/login/<PROVIDER> para la validación.
3. Establecer la sesión autenticada Container Apps agrega una cookie autenticada a la respuesta. Container Apps devuelve su propio token de autenticación al código de cliente.
4. Servir contenido autenticado El cliente incluye la cookie de autenticación en las solicitudes posteriores (controladas automáticamente por explorador). El código de cliente presenta el token de autenticación en el encabezado X-ZUMO-AUTH.

Para los exploradores del cliente, Container Apps puede dirigir automáticamente todos los usuarios no autenticados a /.auth/login/<PROVIDER>. También se pueden presentar a los usuarios uno o varios vínculos /.auth/login/<PROVIDER> para iniciar sesión en la aplicación con sus proveedores preferidos.

Comportamiento de la autorización

En Azure Portal, puede editar la configuración de autenticación de la aplicación de contenedor para establecerla con diferentes comportamientos cuando no se autentica una solicitud entrante. Los encabezados siguientes describen las opciones.

  • Permitir acceso no autenticado: Esta opción aplaza la autorización del tráfico no autenticado al código de la aplicación. Para las solicitudes autenticadas, Container Apps también transfiere información de autenticación en los encabezados HTTP. La aplicación puede usar información en los encabezados para tomar decisiones de autorización para una solicitud.

    Esta opción proporciona más flexibilidad a la hora de controlar las solicitudes anónimas. Por ejemplo, le permite presentar varios proveedores de inicio de sesión a los usuarios. Sin embargo, debe escribir código.

  • Requerir autenticación: esta opción rechaza todo tráfico no autenticado que se dirige a la aplicación. Este rechazo puede ser una acción de redireccionamiento a uno de los proveedores de identidades configurados. En estos casos, un cliente del explorador se redirige a /.auth/login/<PROVIDER> para el proveedor que elija. Si la solicitud anónima procede de una aplicación móvil nativa, la respuesta devuelta es HTTP 401 Unauthorized. También puede configurar el rechazo para que sea HTTP 401 Unauthorized o HTTP 403 Forbidden para todas las solicitudes.

    Con esta opción, no es necesario escribir ningún código de autenticación en la aplicación. Una autorización más precisa, como la autorización específica de rol, se puede controlarse mediante la inspección de las notificaciones del usuario (consulte Access user claims (Acceso a las notificaciones de usuario)).

    Precaución

    Este método de restricción del acceso se aplica a todas las llamadas a la aplicación, lo que puede no ser deseable para las aplicaciones que necesitan una página de inicio disponible públicamente, como muchas aplicaciones de una sola página.

    Nota:

    De manera predeterminada, cualquier usuario del inquilino de Microsoft Entra puede solicitar un token para la aplicación desde Microsoft Entra ID. Puede configurar la aplicación en Microsoft Entra ID si quiere restringir el acceso a la aplicación a un conjunto definido de usuarios.

Personalización del inicio y cierre de sesión

La autenticación de Container Apps proporciona puntos de conexión integrados para iniciar y cerrar sesión. Cuando la característica está habilitada, estos puntos de conexión están disponibles en el prefijo de ruta /.auth en la aplicación de contenedor.

Uso de varios proveedores de inicio de sesión

La configuración del portal no ofrece una manera preparada para presentar varios proveedores de inicio de sesión a los usuarios (por ejemplo, Facebook y Twitter). Sin embargo, no es difícil agregar la funcionalidad a la aplicación. A continuación se describen los pasos necesarios:

Primero, en la página Autenticación / Autorización de Azure Portal, configure cada uno de los proveedores de identidades que desea habilitar.

En Action to take when request is not authenticated (Acción necesaria cuando la solicitud no está autenticada), seleccione Allow Anonymous requests (no action) (Permitir solicitudes anónimas (sin acción)).

En la página de inicio de sesión, en la barra de navegación o en cualquier otra ubicación de la aplicación, agregue un vínculo de inicio de sesión a cada uno de los proveedores que ha habilitado (/.auth/login/<provider>). Por ejemplo:

<a href="/.auth/login/aad">Log in with the Microsoft Identity Platform</a>
<a href="/.auth/login/facebook">Log in with Facebook</a>
<a href="/.auth/login/google">Log in with Google</a>
<a href="/.auth/login/twitter">Log in with Twitter</a>

Cuando el usuario selecciona en uno de los vínculos, la interfaz de usuario de los proveedores correspondientes se muestra al usuario.

Para redirigir al usuario después del inicio de sesión a una dirección URL personalizada, use el parámetro de cadena de consulta post_login_redirect_uri (que no debe confundirse con el URI de redireccionamiento den su configuración de proveedor de identidades). Por ejemplo, para redirigir al usuario a /Home/Index después de iniciar sesión, utilice el siguiente código HTML:

<a href="/.auth/login/<provider>?post_login_redirect_uri=/Home/Index">Log in</a>

Inicio de sesión dirigido por el cliente

En un inicio de sesión dirigido por el cliente, la aplicación inicia la sesión del usuario en el proveedor de identidades mediante un SDK específico del proveedor. Luego, el código de la aplicación envía el token de autenticación resultante a Container Apps para su validación (consulte Flujo de autenticación) mediante una solicitud HTTP POST.

Para validar el token del proveedor, la aplicación de contenedor debe configurarse primero con el proveedor que quiera usar. En el entorno de ejecución, después de recuperar el token de autenticación de su proveedor, publique el token en /.auth/login/<provider> para su validación. Por ejemplo:

POST https://<hostname>.azurecontainerapps.io/.auth/login/aad HTTP/1.1
Content-Type: application/json

{"id_token":"<token>","access_token":"<token>"}

El formato del token varía ligeramente según el proveedor. Consulte la tabla siguiente para más detalles:

Valor del proveedor Necesario en el cuerpo de la solicitud Comentarios
aad {"access_token":"<ACCESS_TOKEN>"} Las propiedades id_token, refresh_token y expires_inson opcionales.
microsoftaccount {"access_token":"<ACCESS_TOKEN>"} o {"authentication_token": "<TOKEN>" authentication_token se prefiere a access_token. La propiedad expires_in es opcional.
Al solicitar el token de los servicios Live, solicite siempre el ámbito wl.basic.
google {"id_token":"<ID_TOKEN>"} La propiedad authorization_code es opcional. Al proporcionar un valor authorization_code, se agregan un token de acceso y un token de actualización al almacén de tokens. Cuando se especifica, authorization_code también puede ir acompañado opcionalmente por una propiedad redirect_uri.
facebook {"access_token":"<USER_ACCESS_TOKEN>"} Use un token de acceso de usuario válido de Facebook.
twitter {"access_token":"<ACCESS_TOKEN>", "access_token_secret":"<ACCES_TOKEN_SECRET>"}

Si el token del proveedor se valida correctamente, la API regresa con un elemento authenticationToken en el cuerpo de la respuesta, que es su token de sesión.

{
    "authenticationToken": "...",
    "user": {
        "userId": "sid:..."
    }
}

Una vez que tenga este token de sesión, puede obtener acceso a los recursos de aplicación protegidos agregando el encabezado X-ZUMO-AUTH a sus solicitudes HTTP. Por ejemplo:

GET https://<hostname>.azurecontainerapps.io/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>

Cierre de sesión de una sesión

Los usuarios pueden cerrar sesión mediante el envío de una solicitud GET al punto de conexión /.auth/logout de la aplicación. La solicitud GET lleva a cabo las siguientes acciones:

  • Borra las cookies de autenticación de la sesión actual.
  • Elimina los tokens del usuario actual del almacén de tokens.
  • Este realiza un cierre de sesión del lado servidor en el proveedor de identidades de Microsoft Entra ID y Google.

A continuación, se muestra un vínculo de cierre de sesión simple en una página web:

<a href="/.auth/logout">Sign out</a>

De manera predeterminada, un cierre de sesión correcto redirige al cliente a la dirección URL /.auth/logout/done. Puede cambiar la página de redirección del inicio de sesión posterior agregando el parámetro de consulta post_logout_redirect_uri. Por ejemplo:

GET /.auth/logout?post_logout_redirect_uri=/index.html

Asegúrese de codificar el valor de post_logout_redirect_uri.

La dirección URL debe hospedarse en el mismo dominio al usar direcciones URL completas.

Acceso a notificaciones de usuario en el código de la aplicación

Para todos los marcos de lenguaje, Container Apps pone las notificaciones del token entrante a disposición del código de la aplicación. Las notificaciones se insertan en los encabezados de solicitud, que están presentes tanto si proceden de un usuario final autenticado como de una aplicación cliente. Las solicitudes externas no están autorizadas para establecer estos encabezados, por lo que solo están presentes si Container Apps los establece. A continuación puede ver algunos encabezados de ejemplo:

  • X-MS-CLIENT-PRINCIPAL-NAME
  • X-MS-CLIENT-PRINCIPAL-ID

El código escrito en cualquier lenguaje o plataforma puede obtener la información que necesita de estos encabezados.

Nota:

Los distintos marcos de lenguaje pueden presentar estos encabezados al código de la aplicación en formatos diferentes, como minúsculas o mayúsculas.

Pasos siguientes

Consulte los artículos siguientes para obtener más información sobre cómo proteger la aplicación de contenedor.