Compartir a través de

Autenticación y autorización en Azure App Service y Azure Functions

  • Artículo

Nota:

A partir del 1 de junio de 2024, todas las aplicaciones de App Service recién creadas tendrán la opción de generar un nombre de host predeterminado único mediante la convención de nomenclatura <app-name>-<random-hash>.<region>.azurewebsites.net. Los nombres de aplicación existentes permanecerán sin cambios.

Ejemplo: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Para obtener más información, consulte Nombre de host predeterminado único para el recurso App Service.

Azure App Service incluye funcionalidades de autenticación y autorización integradas (lo que a veces se denomina "Easy Auth") para que pueda proporcionar inicio de sesión a los usuarios y acceder a los datos escribiendo una cantidad mínima de código (o directamente sin código) en la aplicación web, API RESTful y back-end móvil, así como Azure Functions. En este artículo se describe cómo App Service le ayuda a simplificar la autenticación y autorización para la aplicación.

¿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, deberá asegurarse de que la solución se mantiene actualizada con las actualizaciones más recientes del explorador, el protocolo y la seguridad.

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 para App Service y Azure Functions puede ahorrar tiempo y esfuerzo, ya que proporciona autenticación integrada con proveedores de identidades federados, lo que le permite centrarse en el resto de la aplicación.

  • Azure App Service le permite integrar numerosas funcionalidades de autenticación en su aplicación web o API sin implementarlas usted mismo.
  • Está integrado directamente en la plataforma y no requiere ningún idioma, SDK, experiencia en seguridad ni ningún código en particular.
  • Puede integrar con varios proveedores de inicio de sesión. Por ejemplo, Microsoft Entra, Facebook, Google, X.

Es posible que su aplicación deba admitir situaciones más complejas, como la integración de Visual Studio o el consentimiento incremental. Hay varias soluciones de autenticación diferentes disponibles para admitir estos escenarios. Para más información, consulte Escenarios de identidad.

Proveedores de identidades

App Service 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
Microsoft Entra /.auth/login/aad Inicio de sesión de la plataforma Microsoft Entra de App Service
Facebook /.auth/login/facebook Inicio de sesión con Facebook para App Service
Google /.auth/login/google Inicio de sesión con Google para App Service
X /.auth/login/x Inicio de sesión de X de App Service
GitHub /.auth/login/github Inicio de sesión de GitHub de App Service
Inicio de sesión con Apple /.auth/login/apple Inicio de sesión de App Service con el inicio de sesión de Apple (versión preliminar)
Nuevo proveedor de OpenID Connect /.auth/login/<providerName> Inicio de sesión con OpenID Connect para App Service

Cuando configura esta característica con uno de estos proveedores, su punto de conexión de inicio de sesión está disponible para la autenticación de los usuarios y para la validación de los tokens de autenticación del proveedor. Se puede proporcionar a los usuarios cualquier número de estas opciones de inicio de sesión.

Consideraciones sobre el uso de la autenticación integrada

La habilitación de esta característica hará que todas las solicitudes a la aplicación se redirijan automáticamente a HTTPS, con independencia del valor de configuración de App Service para aplicar HTTPS. Puede deshabilitarlo con la configuración de requireHttps en la configuración de V2. Sin embargo, recomendamos seguir con HTTPS, y debe asegurarse de que ningún token de seguridad se transmita a través de conexiones HTTP no seguras.

App Service puede usarse para la autenticación con o sin restringir el acceso al contenido del sitio y a las API. Las restricciones de acceso se pueden establecer en la sección Autenticación>Configuración de autenticación de la aplicación web. Para restringir el acceso a la aplicación solo a los usuarios autenticados, establezca Acción necesaria cuando la solicitud no está autenticada para iniciar sesión con uno de los proveedores de identidades configurados. Para autenticar pero no restringir el acceso, establezca Acción necesaria cuando la solicitud no está autenticada en "Permitir solicitudes anónimas (ninguna acción)".

Importante

Debe otorgar al registro de cada aplicación su propio permiso y consentimiento. Evite el uso compartido de permisos entre entornos mediante registros de aplicación independientes para ranuras de implementación independientes. Al probar nuevo código, esta práctica puede ayudar a evitar que los problemas afecten a la aplicación de producción.

Funcionamiento

Arquitectura de características

Flujo de autenticación

Comportamiento de la autorización

Almacén de tokens

Registro y seguimiento

Arquitectura de características

El componente de middleware de autenticación y autorización es una característica de la plataforma que se ejecuta en la misma máquina virtual que la aplicación. Cuando está habilitado, cada solicitud HTTP entrante pasa por él antes de que la aplicación lo controle.

Diagrama de arquitectura que muestra las solicitudes que intercepta un proceso en el espacio aislado del sitio 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:

  • Autentica usuarios y clientes con los proveedores de identidades especificados.
  • Valida, almacena y actualiza los tokens de OAuth emitidos por los proveedores de identidades configurados.
  • Administra la sesión autenticada
  • Inserta información de identidad en encabezados de solicitud HTTP.

El módulo se ejecuta por separado del código de la aplicación y se puede configurar mediante Azure Resource Manager o mediante un archivo de configuración. No se necesitan SDK, lenguajes de programación específicos ni cambios en el código de la aplicación.

Arquitectura de características en Windows (implementación sin contenedor)

El módulo de autenticación y autorización se ejecuta como módulo de IIS nativo en el mismo espacio aislado que la aplicación. Cuando está habilitado, cada solicitud HTTP entrante pasa por él antes de que la aplicación lo controle.

Arquitectura de características en Linux y contenedores

El módulo de autenticación y autorización se ejecuta en un contenedor independiente, aislado del código de la aplicación. Con lo que se conoce como patrón de embajador, interactúa con el tráfico entrante para realizar una funcionalidad similar a la de Windows. Dado que 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 su aplicación se pasa con encabezados de solicitud, como se explica a continuación.

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: la aplicación delega el inicio de sesión federado a App Service. Por lo general, suele ser el caso de las aplicaciones de explorador, que pueden presentar la página de inicio de sesión del proveedor al usuario. El código del servidor administra el proceso de inicio de sesión, por lo que también se denomina flujo dirigido por el servidor o flujo de servidor. Este caso se aplica a aplicaciones de explorador y aplicaciones móviles que usan un explorador incrustado para la autenticación.
  • Con el SDK del proveedor: la aplicación inicia manualmente la sesión del usuario con el proveedor y luego envía el token de autenticación a App Service para su validación. Por lo general, suele ser el caso de las aplicaciones sin explorador, que no pueden presentar la página de inicio de sesión del proveedor al usuario. El código de aplicación administra el proceso de inicio de sesión, por lo que también se denomina flujo dirigido por el cliente o flujo de cliente. Este caso se aplica a las API REST, Azure Functions y los clientes de explorador de JavaScript, así como a las aplicaciones de explorador que necesitan más flexibilidad en el proceso de inicio de sesión. También se aplica a las aplicaciones móviles nativas 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 App Service a otra REST API de App Service o Azure Functions se pueden autenticar mediante el flujo dirigido por el servidor. Para obtener más información, vea Personalización del inicio y cierre de sesión.

En la tabla siguiente 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 App Service agrega una cookie autenticada a la respuesta. App Service 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, App Service 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

Importante

De manera predeterminada, esta característica solo proporciona autenticación, no autorización. Es posible que la aplicación todavía tenga que tomar decisiones de autorización, además de las comprobaciones que configure aquí.

En Azure Portal, puede configurar App Service con varios comportamientos cuando la solicitud entrante no esté autenticada. Los encabezados siguientes describen las opciones.

Restricción del acceso

  • Permitir solicitudes no autenticadas Esta opción aplaza la autorización del tráfico no autenticado al código de la aplicación. Para las solicitudes autenticadas, App Service también transfiere información de autenticación en los encabezados HTTP.

    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 rechazará todo tráfico no autenticado a la aplicación. La acción a realizar se especifica en la sección Solicitudes no autenticadas.

    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:

    Al usar el proveedor de identidades de Microsoft con los usuarios de su organización, el comportamiento predeterminado es que cualquier usuario del inquilino de Microsoft Entra pueda solicitar un token para la aplicación. Puede configurar la aplicación en Microsoft Entra si quiere restringir el acceso a la aplicación a un conjunto definido de usuarios. App Service también ofrece algunas comprobaciones de autorización integradas básicas que pueden ayudar con algunas validaciones. Para obtener más información sobre la autorización en Microsoft Entra, consulte Conceptos básicos de autorización de Microsoft Entra.

Solicitudes no autenticadas

  • Redireccionamiento HTTP 302 Encontrado: recomendado para sitios webRedirige la acción 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.
  • HTTP 401 No autorizado: recomendado para las API Si la solicitud anónima procede de una aplicación móvil nativa, la respuesta devuelta es un HTTP 401 Unauthorized. También puede configurar el rechazo para que sea un HTTP 401 Unauthorized para todas las solicitudes.
  • HTTP 403 Prohibido Configura el rechazo para que sea un HTTP 403 Forbidden para todas las solicitudes.
  • HTTP 404 No encontrado Configura el rechazo para que sea un HTTP 404 Not found para todas las solicitudes.

Almacén de tokens

App Service proporciona un almacén de tokens integrado, que es un repositorio de tokens que están asociados a los usuarios de las aplicaciones web, API o aplicaciones móviles nativas. Al habilitar la autenticación con cualquier proveedor, este almacén de tokens pasa a estar inmediatamente disponible para la aplicación, si el código de aplicación necesita acceder a los datos de estos proveedores en nombre del usuario, como:

  • publicar en la escala de tiempo de Facebook del usuario autenticado
  • leer los datos corporativos del usuario mediante Microsoft Graph API

Normalmente, debe escribir código para recopilar, almacenar y actualizar estos tokens en la aplicación. Con el almacén de tokens, simplemente recupera los tokens cuando los necesita e indica a App Service que los actualice cuando dejan de ser válidos.

Los tokens de identificador, los tokens de acceso y los tokens de actualización se almacenaron en caché durante la sesión autenticada y solamente el usuario asociado puede acceder a ellos.

Si no necesita trabajar con tokens en la aplicación, puede deshabilitar el almacén de tokens en la página Autenticación/Autorización de la aplicación.

Registro y seguimiento

Si habilita el registro de aplicaciones, verá los seguimientos de autenticación y autorización directamente en los archivos de registro. Si ve un error de autenticación que no esperaba, puede encontrar cómodamente todos los detalles examinando los registros de aplicaciones existentes. Si habilita el seguimiento de solicitudes erróneas, puede ver exactamente qué rol puede haber desempeñado el módulo de autenticación y autorización en una solicitud errónea. En los registros de seguimiento, busque las referencias a un módulo denominado EasyAuthModule_32/64.

Consideraciones al usar Azure Front Door

Al usar Azure App Service con Easy Auth detrás de Azure Front Door u otros servidores proxy inversos, es necesario tener en cuenta algunos aspectos adicionales.

  1. Deshabilitación del almacenamiento en caché para el flujo de trabajo de autenticación

    Consulte Deshabilitación de la caché para el flujo de trabajo de autenticación para más información sobre cómo configurar reglas en Azure Front Door para deshabilitar el almacenamiento en caché para las páginas relacionadas con la autenticación y la autorización.

  2. Uso del punto de conexión de Front Door para redireccionamientos

    App Service normalmente no es accesible directamente cuando se expone a través de Azure Front Door. Esto se puede evitar, por ejemplo, al exponer App Service a través de Private Link en Azure Front Door Premium. Para evitar que el flujo de trabajo de autenticación redirija el tráfico de nuevo a App Service directamente, es importante configurar la aplicación para volver a redirigir a https://<front-door-endpoint>/.auth/login/<provider>/callback.

  3. Asegúrese de que App Service usa el URI de redirección correcto.

    En algunas configuraciones, App Service usa el FQDN de App Service como el URI de redireccionamiento en lugar del FQDN de Front Door. Esto provocará un problema cuando el cliente se redirige a App Service en lugar de Front Door. Para cambiarlo, la configuración forwardProxy debe establecerse en Standard para que App Service respete el encabezado X-Forwarded-Host establecido por Azure Front Door.

    Otros servidores proxy inversos, como Azure Application Gateway o productos de terceros, pueden usar encabezados diferentes y necesitan una configuración forwardProxy diferente.

    Esta configuración no se puede realizar mediante Azure Portal y debe realizarse a través de az rest:

    Exportar configuración

    az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method get > auth.json

    Actualización de la configuración

    Buscar

    "httpSettings": {
  "forwardProxy": {
    "convention": "Standard"
  }
}

    y asegúrese de que convention está establecido en Standard para respetar el encabezado X-Forwarded-Host usado por Azure Front Door.

    Importar configuración

    az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json

Más recursos

Ejemplos: