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

Azure App Service proporciona autenticación integrada (inicio de sesión de usuarios) y autorización (proporcionar acceso a datos seguros). Estas funcionalidades a veces se denominan Easy Auth. Puede usarlos para iniciar sesión de usuarios y acceder a datos escribiendo poco o ningún código en la aplicación web, API RESTful, servidor móvil y funciones.

En este artículo se describe cómo App Service le ayuda a simplificar la autenticación y autorización para la aplicación.

Motivos para usar la autenticación integrada

Para implementar la autenticación y la autorización, puede usar las características de seguridad agrupadas en el marco web que prefiera o puede escribir sus propias herramientas. La implementación de una solución segura para la autenticación y autorización puede llevar un esfuerzo significativo. Debe seguir los procedimientos recomendados y estándares del sector. También debe asegurarse de que la solución se mantenga actualizada con las actualizaciones más recientes de seguridad, protocolo y explorador.

Las funcionalidades integradas de App Service y Azure Functions pueden ahorrar tiempo y esfuerzo al proporcionar autenticación integrada con proveedores de identidades federados, por lo que puede centrarse en el resto de la aplicación.

Con App Service, puede integrar las funcionalidades de autenticación en la aplicación web o la API sin implementarlas usted mismo. Esta característica se integra directamente en la plataforma y no requiere ningún lenguaje, SDK, experiencia en seguridad ni código concretos. Puede integrarlo con varios proveedores de inicio de sesión, como Microsoft Entra, Facebook, Google y X.

Es posible que la aplicación tenga que admitir escenarios más complejos, como la integración de Visual Studio o el consentimiento incremental. Hay varias soluciones de autenticación disponibles para admitir estos escenarios. Para más información, consulte Escenarios y recomendaciones de autenticación.

Proveedores de identidades

App Service usa la identidad federada. Un proveedor de identidades de Microsoft o que no es de Microsoft administra automáticamente las identidades de usuario y el flujo de autenticación. De forma predeterminada, están disponibles los siguientes proveedores de identidades:

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 la autenticación integrada hace que todas las solicitudes a la aplicación se redirijan automáticamente a HTTPS, independientemente de la configuración de App Service para aplicar HTTPS. Puede deshabilitar esta redirección automática usando la configuración requireHttps en la V2. Sin embargo, se recomienda seguir usando HTTPS y asegurarse de que ningún token de seguridad se transmita nunca a través de conexiones HTTP no seguras.

Puede usar App Service para la autenticación con o sin restringir el acceso al contenido y las API del sitio. Establezca restricciones de acceso en la sección Configuración>Autenticación>Configuración de autenticación de su aplicación web:

• Para restringir el acceso de la aplicación solo a usuarios autenticados, establezca Acción que se realizará cuando no se autentique la solicitud para iniciar sesión con uno de los proveedores de identidades configurados.
• Para autenticar pero no restringir el acceso, establezca Acción que se realizará cuando la solicitud no esté autenticada en Permitir solicitudes anónimas (sin acción).

Funcionamiento

Arquitectura de funcionalidades

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. Al habilitarlo, cada solicitud HTTP entrante pasa a través de ese componente antes de que la aplicación la controle.

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

• Autentica a usuarios y clientes con los proveedores de identidad especificados.
• Valida, almacena y actualiza 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. Puede configurarlo mediante la configuración de 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. Al habilitarlo, cada solicitud HTTP entrante pasa a través de ella antes de que la aplicación la controle.

Arquitectura de características en Linux y contenedores

El módulo de autenticación y autorización se ejecuta en un contenedor independiente que está aislado del código de la aplicación. El módulo usa el patrón Ambassador para interactuar con el tráfico entrante para realizar una funcionalidad similar a la de Windows. Dado que no se ejecuta en proceso, no es posible realizar ninguna integración directa con marcos de lenguaje específicos. Sin embargo, la información pertinente que necesita la aplicación se transmite a través de los encabezados de solicitud.

Flujo de autenticación

El flujo de autenticación es el mismo para todos los proveedores. Difiere 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 en App Service. Esta delegación suele ser el caso de las aplicaciones de explorador, que puede presentar la página de inicio de sesión del proveedor al usuario. El código de servidor administra el proceso de inicio de sesión, por lo que también se denomina flujo dirigido al 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 sesión de los usuarios en el proveedor manualmente. A continuación, envía el token de autenticación a App Service para su validación. Este proceso 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 la 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 del explorador JavaScript, además de 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 inician sesión de los usuarios mediante el SDK del proveedor.

Las llamadas desde una aplicación de explorador de confianza de App Service a otra API REST en App Service o Azure Functions se pueden autenticar a través del flujo dirigido por el servidor. Para más información, consulte Personalizar el inicio y cierre de sesión en la autenticación de Azure App Service.

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

Para los exploradores del cliente, App Service puede dirigir automáticamente todos los usuarios no autenticados a /.auth/login/<provider>. También puede presentar a los usuarios con uno o varios /.auth/login/<provider> enlaces para iniciar sesión en la aplicación mediante el proveedor que elijan.

Comportamiento de la autorización

En Azure Portal, puede configurar App Service con varios comportamientos cuando no se autentica una solicitud entrante. En las secciones siguientes se describen las opciones.

Acceso restringido

• 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, tienes que escribir código.

• Requerir autenticación: esta opción rechaza todo tráfico no autenticado que se dirige a la aplicación. La acción específica que se debe realizar se especifica en la sección Solicitudes no autenticadas más adelante en este artículo.

  Con esta opción, no es necesario escribir ningún código de autenticación en la aplicación. Puede controlar la autorización más fina, como la autorización específica del rol, inspeccionando las notificaciones del 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. Si se necesitan excepciones, debe configurar rutas de acceso excluidas en un archivo de configuración.

  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.

Cuando usa el proveedor de identidades de Microsoft para los usuarios de su organización, el comportamiento predeterminado es que cualquier usuario del inquilino de Microsoft Entra puede 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 web: redirige 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: devuelve una HTTP 401 Unauthorized respuesta si la solicitud anónima procede de una aplicación móvil nativa. También puede configurar el rechazo para que sea HTTP 401 Unauthorized para todas las solicitudes.
• HTTP 403 Prohibido: configura el rechazo para que sea HTTP 403 Forbidden para todas las solicitudes.
• HTTP 404 No encontrado: configura el rechazo para que sea HTTP 404 Not found para todas las solicitudes.

Almacén de tokens

App Service proporciona un almacén de tokens integrado. Un almacén de tokens es un repositorio de tokens que están asociados a los usuarios de las aplicaciones web, las API o las 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 la aplicación necesita acceder a los datos de estos proveedores en nombre del usuario, normalmente debe escribir código para recopilar, almacenar y actualizar estos tokens en la aplicación. Las acciones pueden incluir:

• Publicar en el muro de Facebook del usuario autenticado.
• Lea los datos corporativos del usuario mediante Microsoft Graph API.

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 almacenan en caché para la sesión autenticada. Solo 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áginaAutenticación de > de la aplicación.

Registro y seguimiento

Si habilita el registro de aplicaciones, los seguimientos de autenticación y autorización aparecen 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 con errores, puede ver exactamente qué rol podría desempeñar el módulo de autenticación y autorización en una solicitud con error. En los registros de seguimiento, busque las referencias a un módulo denominado EasyAuthModule_32/64.

Mitigación de falsificación de solicitudes entre sitios

La autenticación de App Service mitiga la falsificación de solicitudes entre sitios inspeccionando las solicitudes de los clientes bajo las siguientes condiciones:

• Es una POST solicitud que se autentica a través de una cookie de sesión.
• La solicitud procede de un explorador conocido, determinado por el encabezado HTTP User-Agent .
• Falta el encabezado HTTP Origin o HTTP Referer o no está en la lista configurada de dominios externos aprobados para el redireccionamiento.
• Falta el encabezado HTTP Origin o no está en la lista configurada de orígenes de uso compartido de recursos entre orígenes (CORS).

Cuando una solicitud cumple todas estas condiciones, la autenticación de App Service la rechaza automáticamente. Puede sortear esta lógica de mitigación agregando el dominio externo a la lista de redireccionamientos en Configuración>Autenticación>Editar configuración de autenticación>URLs de redirección externas permitidas.

Consideraciones sobre el uso de Azure Front Door

Cuando use Azure App Service con autenticación detrás de Azure Front Door u otros servidores proxy inversos, tenga en cuenta las siguientes acciones.

Deshabilitación del almacenamiento en caché de Azure Front Door

Deshabilite el almacenamiento en caché de Azure Front Door para el flujo de trabajo de autenticación.

Uso del punto de conexión de Azure Front Door para redireccionamientos

Normalmente, no se puede acceder directamente a App Service cuando está expuesto por Azure Front Door. Puede evitar este comportamiento, por ejemplo, exponiendo App Service mediante Azure Private Link en Azure Front Door Premium. Para evitar que el flujo de trabajo de autenticación redirija el tráfico directamente a App Service. Para obtener más información, consulte URI de redirección.

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

En algunas configuraciones, App Service usa su nombre de dominio completo (FQDN) como URI de redirección, en lugar del FQDN de Azure Front Door. Esta configuración provoca un problema cuando el cliente se redirige a App Service en lugar de Azure Front Door. Para cambiarlo, establezca forwardProxy en Standard para que App Service respete el X-Forwarded-Host encabezado establecido en Azure Front Door.

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

No se puede cambiar la forwardProxy configuración mediante Azure Portal. Debe usar az rest.

Configuración de exportació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

Actualizar configuración

Busque:

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

Asegúrese de que convention está establecido en Standard para respetar el X-Forwarded-Host encabezado que usa 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

Contenido relacionado

Para más información sobre la autenticación de App Service, consulte:

• Configuración de una aplicación de App Service o Azure Functions para usar el inicio de sesión de Microsoft Entra
• Personalización del inicio y cierre de sesión en la autenticación de Azure App Service
• Trabajo con tokens de OAuth en la autenticación de Azure App Service
• Uso de identidades de usuario en la autenticación de Azure App Service
• Configuración basada en archivos en la autenticación de Azure App Service

Para obtener ejemplos, vea:

• Inicio rápido: Incorporación de la autenticación de aplicación a una aplicación web en Azure App Service
• Tutorial: Autenticación y autorización de usuarios de extremo a extremo en Azure App Service
• Integración de .NET Core de Azure AppService Easy Auth (contenido que no es de GitHub de Microsoft)
• Obtención de la autenticación de Azure App Service que funciona con .NET Core (contenido que no es de GitHub de Microsoft)