Exploración de la autenticación y autorización en App Service

6 minutos

Azure App Service proporciona compatibilidad integrada con la autenticación y la autorización. Puede proporcionar inicio de sesión a los usuarios y acceder a los datos con una cantidad mínima de código, o directamente sin código, en la aplicación web, la Restful API, el back-end para dispositivos móviles o Azure Functions.

¿Por qué usar la autenticación integrada?

No es necesario usar App Service para la autenticación y autorización. Muchos marcos web están incluidos en las características de seguridad y puede usarlos si lo desea. Si necesita más flexibilidad de la que App Service proporciona, también puede escribir sus propias utilidades.

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 permite integrar diversas funcionalidades de autenticación en la aplicación web o la API sin implementarlas usted mismo.
La autenticación está integrada directamente en la plataforma y no requiere ningún lenguaje, SDK, conocimientos de seguridad o código en particular.
Puede integrar con varios proveedores de inicio de sesión. Por ejemplo, Microsoft Entra ID, Facebook, Google, X.

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
Plataforma de identidad de Microsoft	`/.auth/login/aad`	Inicio de sesión de la plataforma de identidad de Microsoft 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/twitter`	Inicio de sesión de X de App Service
Nuevo proveedor de OpenID Connect	`/.auth/login/<providerName>`	Inicio de sesión con OpenID Connect para App Service
GitHub	`/.auth/login/github`	Inicio de sesión de GitHub de App Service

Cuando habilita la autenticación y autorización con uno de estos proveedores, su punto de conexión de inicio de sesión está disponible para la autenticación de 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 sesión.

Funcionamiento

El módulo de autenticación y autorización se ejecuta en el mismo espacio aislado que el código de aplicación. Cuando está activada, todas las peticiones HTTP entrantes pasan por ella antes de ser entregadas al código de la aplicación. Este módulo controla varios aspectos de la aplicación:

Autentica a los 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.

Nota:

En Linux y los contenedores, el módulo de autenticación y autorización se ejecuta en un contenedor independiente, aislado del código de la aplicación. Puesto que no se ejecuta en proceso, no es posible la integración directa con plataformas de lenguaje específicas.

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 SDK de 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 pueden 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 y se conoce como flujo dirigido al servidor o flujo de servidor.
Con SDK de proveedor: la aplicación inicia la sesión de los usuarios en el proveedor manualmente y, a continuación, 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 la aplicación administra el proceso de inicio de sesión y se conoce como flujo dirigido por el cliente o flujo de cliente. Esto se aplica a las API de REST, Azure Functions, los clientes del explorador JavaScript y las aplicaciones móviles nativas que inician la sesión de los usuarios mediante el SDK del proveedor.

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

Paso	Sin el SDK del proveedor	Con el SDK del proveedor
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.
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.
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.
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` (controlado automáticamente por SDK de cliente de Mobile Apps).

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

En Azure Portal, puede configurar App Service con varios comportamientos cuando una solicitud entrante no esté autenticada.

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. Le permite presentar varios proveedores de inicio de sesión a los usuarios.
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.

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.

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,

Registro y seguimiento

Si habilita el registro de aplicaciones, los seguimientos de autenticación y autorización se recopilan 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.