Protección de ASP.NET Core Blazor WebAssembly

Las aplicaciones Blazor WebAssembly se protegen de la misma manera que las aplicaciones de página única (SPA). Hay varios métodos para autenticar a los usuarios en las SPA, pero el enfoque más común y completo consiste en usar una implementación basada en el protocolo OAuth 2.0, como OpenID Connect (OIDC).

La documentación de seguridad de Blazor WebAssembly se centra principalmente en cómo realizar tareas de autenticación y autorización de usuarios. Para la cobertura de concepto general de OAuth 2.0/OIDC, consulte los recursos de la sección Recursos adicionalesdel artículo de información general principal.

Seguridad del lado cliente/SPA de datos confidenciales y credenciales

El código base de .NET/C# de una aplicación Blazor WebAssembly se sirve a los clientes y el código de la aplicación no se puede proteger de la inspección y manipulación por parte de los usuarios. Nunca coloque credenciales o secretos en una Blazor WebAssembly aplicación, como secretos de aplicación, cadena de conexión s, contraseñas, código .NET/C# privado u otros datos confidenciales.

Para proteger el código de .NET/C# y usar las características de protección de datos de ASP.NET Core para proteger los datos, use una API web de ASP.NET Core del lado servidor. Haga que la aplicación Blazor WebAssembly del lado cliente llame a la API web del lado servidor para proteger las características de la aplicación y el procesamiento de datos. Para obtener más información, consulte Llamada a una API web desde una aplicación Blazor ASP.NET Core y los artículos de este nodo.

Para las pruebas de desarrollo local, se recomienda la herramienta Secret Manager para proteger los datos confidenciales.

Biblioteca de autenticación

Blazor WebAssemblyadmite la autenticación y autorización de aplicaciones mediante OIDC a través de la Microsoft.AspNetCore.Components.WebAssembly.Authentication biblioteca mediante la plataforma Microsoftidentity. La biblioteca proporciona un conjunto de primitivas para la autenticación sin problemas en back-ends de ASP.NET Core. La biblioteca puede realizar la autenticación sobre cualquier proveedor de Identity (IP) de terceros que admita OIDC, que se denominan proveedores de OpenID (OP).

La compatibilidad de autenticación en la biblioteca Blazor WebAssembly (Authentication.js) se sustenta en Microsoft Authentication Library (MSAL, msal.js), que se usa para gestionar los detalles de los protocolos de autenticación subyacentes. La biblioteca Blazor WebAssembly solo admite el flujo de código de autorización Proof Key for Code Exchange (PKCE). La concesión implícita no se admite.

Existen otras opciones para la autenticación de las SPA, como el uso de cookies de SameSite. Sin embargo, el diseño de ingeniería de Blazor WebAssembly usa OAuth y OIDC como la mejor opción de autenticación en las aplicaciones de Blazor WebAssembly. Se ha elegido la autenticación basada en tokens basada en JSON Web Token (JWT) antes que la autenticación basada en cookie por razones funcionales y de seguridad:

• El uso de un protocolo basado en tokens ofrece menos vulnerabibilidades, ya que los tokens no se envían en todas las solicitudes.
• Los tokens se envían de forma explícita al servidor, por lo que los puntos de conexión de servidor no requieren protección contra la falsificación de solicitud entre sitios (CSRF). Esto permite hospedar aplicaciones de Blazor WebAssembly junto con aplicaciones de páginas de Razor o de MVC.
• Los tokens tienen permisos más restringidos que las cookies. Por ejemplo, los tokens no se pueden usar para administrar la cuenta de usuario o cambiar su contraseña a menos que esa funcionalidad se implemente de forma explícita.
• Los tokens tienen una duración corta, una hora, lo que limita la ventana de ataque. Los tokens también se pueden revocar en cualquier momento.
• Los JWT independientes ofrecen garantías al cliente y al servidor sobre el proceso de autenticación. Por ejemplo, un cliente tiene los medios para detectar y validar que los tokens que recibe son legítimos y se han emitido como parte de un proceso de autenticación determinado. Si un tercero intenta cambiar un token en medio del proceso de autenticación, el cliente puede detectar el token cambiado y evitar usarlo.
• Los tokens con OAuth y OIDC no se basan en que el agente de usuario se comporte correctamente para asegurarse de que la aplicación sea segura.
• Los protocolos basados en token, como OAuth y OIDC, permiten autenticar y autorizar usuarios en aplicaciones Blazor Webassembly independientes con el mismo conjunto de características de seguridad.

Importante

En el caso de las versiones de ASP.NET Core que adoptan Duende Identity Server en plantillas de proyecto de Blazor, Duende Software puede requerir que pague una cuota de licencia por el uso en producción de Duende Identity Server. Para más información, vea Migración de ASP.NET Core 5.0 a 6.0.

Proceso de autenticación con OIDC

La biblioteca Microsoft.AspNetCore.Components.WebAssembly.Authentication ofrece varias primitivas para implementar la autenticación y autorización mediante OIDC. En términos generales, la autenticación funciona de la siguiente manera:

• Cuando un usuario anónimo selecciona el botón de inicio de sesión o solicita un componente de Razor o una página con el atributo [Authorize] aplicado, se le redirige a la página de inicio de sesión de la aplicación (/authentication/login).
• En la página de inicio de sesión, la biblioteca de autenticación se prepara para un redireccionamiento al punto de conexión de autorización. El punto de conexión de autorización está fuera de la aplicación de Blazor WebAssembly y se puede hospedar en un origen independiente. El punto de conexión es responsable de determinar si el usuario está autenticado y de emitir uno o más tokens en respuesta. La biblioteca de autenticación proporciona una devolución de llamada de inicio de sesión para recibir la respuesta de autenticación.
  • Si el usuario no está autenticado, se le redirige al sistema de autenticación subyacente, que normalmente es ASP.NET Core Identity.
  • Si el usuario ya se ha autenticado, el punto de conexión de autorización genera los tokens adecuados y devuelve al explorador al punto de conexión de devolución de llamada de inicio de sesión (/authentication/login-callback).
• Cuando la aplicación de Blazor WebAssembly carga el punto de conexión de devolución de llamada de inicio de sesión (/authentication/login-callback), se procesa la respuesta de autenticación.
  • Si el proceso de autenticación se completa correctamente, el usuario se autentica y, opcionalmente, se devuelve a la dirección URL protegida original que haya solicitado.
  • Si por algún motivo se produce un error en el proceso de autenticación, se envía al usuario a la página de inicio de sesión con errores (/authentication/login-failed), donde se muestra un error.

Componente de Authentication

El componente Authentication (Authentication.razor) controla las operaciones de autenticación remota y permite a la aplicación:

• Configurar rutas de aplicación para los estados de autenticación.
• Establecer el contenido de la interfaz de usuario para los estados de autenticación.
• Administrar el estado de la autenticación.

Las acciones de autenticación, como el registro o la firma de un usuario, se pasan al componente RemoteAuthenticatorViewCore<TAuthenticationState> del marco de Blazor, que persiste y controla el estado en las operaciones de autenticación.

Para obtener más información y ejemplos, consulte Otros escenarios de seguridad de Blazor WebAssembly en ASP.NET Core.

Autorización

En aplicaciones de Blazor WebAssembly, las comprobaciones de autorización pueden omitirse porque los usuarios pueden modificar todos los códigos del lado cliente. Lo mismo se aplica a todas las tecnologías de aplicaciones del lado cliente, incluidas las plataformas JavaScript SPA o las aplicaciones nativas para cualquier sistema operativo.

Realice siempre las comprobaciones de autorización en el servidor dentro de cualquier punto de conexión de la API al que acceda su aplicación del lado cliente.

Personalización de la autenticación

Blazor WebAssembly proporciona métodos de agregación y recuperación de parámetros adicionales para la biblioteca de autenticación subyacente a fin de realizar operaciones de autenticación remota con proveedores de identity externos.

Para pasar parámetros adicionales, NavigationManager admite el paso y la recuperación del estado de la entrada del historial al realizar cambios en la ubicación externa. Para obtener más información, consulte los siguientes recursos:

• BlazorArtículo de Blazor Aspectos básicos>Enrutamiento y navegación
  • Estado del historial de navegación
  • Opciones de navegación
• Documentación de MDN: API de historial

El estado almacenado por la API del historial proporciona las siguientes ventajas para la autenticación remota:

• El estado que se pasa al punto de conexión de la aplicación protegida se vincula a la navegación realizada para autenticar al usuario en el punto de conexión de authentication/login.
• Se evita la codificación y descodificación adicionales de trabajos.
• Se reducen las vulnerabilidades. A diferencia del uso de la cadena de consulta para almacenar el estado de navegación, una navegación de nivel superior o la influencia desde un origen diferente no pueden establecer el estado almacenado por la API de historial.
• Cuando se usa la autenticación correcta, la entrada del historial se reemplaza, por lo que el estado adjunto a la entrada del historial se quita, y no es necesario realizar una limpieza.

InteractiveRequestOptions representa la solicitud al proveedor de identity para iniciar sesión o aprovisionar un token de acceso.

NavigationManagerExtensions proporciona el método NavigateToLogin para una operación de inicio de sesión y NavigateToLogout para una operación de cierre de sesión. Los métodos llaman a NavigationManager.NavigateTo, y se establece el estado de entrada del historial con un InteractiveRequestOptions que se haya pasado o una nueva instancia de InteractiveRequestOptions creada por el método para:

• Un usuario que inicia sesión (InteractionType.SignIn) con el URI actual para la dirección URL de retorno.
• Un usuario que cierra sesión (InteractionType.SignOut) con la dirección URL de retorno.

En el artículo Escenarios de seguridad adicionales de ASP.NET Core Blazor WebAssembly se tratan los siguientes escenarios de autenticación:

• Personalización del proceso de inicio de sesión
• Cierre de sesión con una dirección URL de retorno personalizada
• Personalización de opciones antes de obtener un token de forma interactiva
• Personalización de opciones al usar un IAccessTokenProvider
• Obtención de la ruta de acceso de inicio de sesión desde las opciones de autenticación

Requerimiento de autorización para toda la aplicación

Aplique el atributo [Authorize] (documentación de la API) a cada componente Razor de la aplicación utilizando alguno de los siguientes enfoques:

• En el archivo Imports de la aplicación, agregue una directiva \@using para el espacio de nombres Microsoft.AspNetCore.Authorization con una directiva @attribute para el atributo [Authorize].

  _Imports.razor:

  @using Microsoft.AspNetCore.Authorization
  @attribute [Authorize]
  

  Permitir el acceso anónimo al componente Authentication para permitir el redireccionamiento al proveedor de identity. Agregue el código siguiente Razor al elemento Authentication, justo debajo de la directiva @page.

  Authentication.razor:

  @using Microsoft.AspNetCore.Components.WebAssembly.Authentication
  @attribute [AllowAnonymous]
  

• Agregue el atributo a cada componente Razor en la directiva @page:

  @using Microsoft.AspNetCore.Authorization
  @attribute [Authorize]
  

Nota:

No se admite la configuración de un elemento AuthorizationOptions.FallbackPolicy en una directiva con RequireAuthenticatedUser.

Uso de un registro de aplicación del proveedor de identity por aplicación

Algunos de los artículos de esta Información general pertenecen a escenarios de hospedaje de Blazor que implican dos o más aplicaciones. Una aplicación independiente Blazor WebAssembly usa la API web con usuarios autenticados para acceder a los recursos del servidor y a los datos proporcionados por una aplicación de servidor.

Cuando este escenario se implementa en ejemplos de documentación, se usan dos registros del proveedor de identity, uno para la aplicación cliente y otro para la aplicación de servidor. El uso de registros independientes, por ejemplo, en el identificador de Entra de Microsoft, no es estrictamente necesario. Sin embargo, el uso de dos registros es un procedimiento recomendado de seguridad porque aísla los registros por aplicación. El uso de registros independientes también permite la configuración independiente de los registros de cliente y servidor.

Tokens de actualización

Aunque los tokens de actualización no se pueden proteger en las aplicaciones Blazor WebAssembly, se pueden usar si los implementa con las estrategias de seguridad adecuadas.

Para las aplicaciones independientes Blazor WebAssembly de ASP.NET Core en .NET 6 o versiones posteriores, se recomienda usar lo siguiente:

• El flujo de código de autorización (código) de OAuth 2.0 con una clave de prueba para el intercambio de código (PKCE).
• Un token de actualización que tiene una expiración corta.
• Un token de actualización rotado.
• Un token de actualización con una expiración después de la cual se requiere un nuevo flujo de autorización interactiva para actualizar las credenciales del usuario.

Para obtener más información, consulte los siguientes recursos:

• Tokens de actualización de la plataforma de identity de Microsoft: vigencia del token de actualización
• OAuth 2.0 para aplicaciones basadas en el explorador (especificación IETF)

Establecimiento de notificaciones para usuarios

Las aplicaciones a menudo requieren notificaciones para usuarios basadas en una llamada de API web a un servidor. Por ejemplo, las notificaciones se usan con frecuencia para establecer autorizaciones en una aplicación. En estos casos, la aplicación solicita un token de acceso para acceder al servicio y usa dicho token para obtener los datos de usuario para crear notificaciones.

En los siguientes temas podrá ver algunos ejemplo:

• Otros escenarios: Personalizar el usuario
• ASP.NET Core Blazor WebAssembly con roles y grupos de identificadores de Microsoft Entra

Compatibilidad con la representación previa

La representación previa no se admite para los puntos de conexión de autenticación (segmento de ruta de acceso /authentication/).

Para más información, vea Escenarios de seguridad adicionales de Blazor WebAssembly en ASP.NET Core.

Azure App Service en Linux con Identity Server

Al realizar una implementación en Azure App Service en Linux con Identity Server, especifique el emisor de forma explícita.

Para más información, consulte Uso de Identity para proteger un back-end de API web para SPA.

Autenticación de Windows

No se recomienda usar la autenticación de Windows con Blazor Webassembly ni ningún otro marco de SPA. Se recomienda usar protocolos basados en tokens, en lugar de la autenticación de Windows, como OIDC con Servicios de federación de Active Directory (AD FS).

Si se usa la autenticación de Windows con Blazor Webassembly o con cualquier otro marco de SPA, se necesitan medidas adicionales para proteger la aplicación ante tokens de falsificación de solicitud entre sitios (CSRF). Los mismos problemas que se aplican a las cookies se aplican a la autenticación de Windows y, además, la autenticación de Windows no ofrece ningún mecanismo para evitar el uso compartido del contexto de autenticación entre orígenes. Las aplicaciones que utilizan la autenticación de Windows sin la protección adicional de CSRF se deben limitar, al menos, a la intranet de una organización y no usarse en la red abierta de Internet.

Para obtener más información, vea Prevención de ataques de falsificación de solicitud entre sitios (XSRF/CSRF) en ASP.NET Core.

Protección de un centro de conectividad SignalR

Para proteger un centro de conectividad SignalR en el proyecto de API de servidor, aplique el atributo [Authorize] a la clase de centro de conectividad o a los métodos de la clase de centro de conectividad.

En un proyecto de cliente con representación previa, como Blazor WebAssembly hospedado (ASP.NET Core en .NET 7 o una versión anterior) o Blazor Web App (ASP.NET Core en .NET 8 o una versión posterior), consulta las instrucciones en la guía ASP.NET Core BlazorSignalR.

En un componente de proyecto de cliente sin representación previa, como aplicaciones independientes Blazor WebAssemblyo que no sean de explorador, proporcione un token de acceso a la conexión del centro de conectividad, como se muestra en el ejemplo siguiente. Para más información, vea Autenticación y autorización en ASP.NET Core SignalR.

@using Microsoft.AspNetCore.Components.WebAssembly.Authentication
@inject IAccessTokenProvider TokenProvider
@inject NavigationManager Navigation

...

var tokenResult = await TokenProvider.RequestAccessToken();

if (tokenResult.TryGetToken(out var token))
{
    hubConnection = new HubConnectionBuilder()
        .WithUrl(Navigation.ToAbsoluteUri("/chathub"), 
            options => { options.AccessTokenProvider = () => Task.FromResult(token?.Value); })
        .Build();

  ...
}

Registro

Esta sección se aplica a las aplicaciones Blazor WebAssembly de ASP.NET Core en .NET 7 o versiones posteriores.

Para habilitar el registro de depuración o seguimiento, consulte la sección Registro de autenticación (Blazor WebAssembly) en la versión 7.0 o una versión posterior del artículo Registro de Blazor en ASP.NET Core.

Espacio aislado de WebAssembly

El espacio aislado de WebAssembly restringe el acceso al entorno del sistema que ejecuta código de WebAssembly, incluido el acceso a subsistemas de E/S, el almacenamiento del sistema y los recursos, y el sistema operativo. El aislamiento entre el código de WebAssembly y el sistema que ejecuta el código hace que WebAssembly sea un marco de codificación seguro para los sistemas. Sin embargo, WebAssembly es vulnerable a ataques de canal lateral en el nivel de hardware. Se aplican precauciones normales y la diligencia debida en el suministro del hardware y la imposición de limitaciones en el acceso al hardware.

WebAssembly no es propiedad de Microsoft ni tampoco se ocupa de su mantenimiento.

Para obtener más información, vea los siguientes recursos de W3C:

• WebAssembly: Seguridad
• Especificación de WebAssembly: Consideraciones de seguridad
• Grupo de la comunidad de WebAssembly de W3C: Comentarios y problemas: el vínculo al grupo de la comunidad de WebAssembly de W3C solo se proporciona como referencia, para aclarar que los errores y las vulnerabilidades de seguridad de WebAssembly se revisan constantemente, y el explorador suele notificarlos y corregirlos. No envíe comentarios ni informes de errores sobre Blazor al grupo de la comunidad de WebAssembly de W3C. Los comentarios sobre Blazor deben notificarse a la unidad de productos de Microsoft ASP.NET Core. Si la unidad de productos de Microsoft determina que existe un problema subyacente con WebAssembly, realizará los pasos adecuados para notificar el problema al grupo de la comunidad de WebAssembly de W3C.

Guía de implementación

En los artículos de esta introducción se ofrecen detalles sobre la autenticación de usuarios en aplicaciones de Blazor WebAssembly con proveedores específicos.

Aplicaciones de Blazor WebAssembly independientes:

• Instrucciones generales para los proveedores de OIDC y la biblioteca de autenticación WebAssembly
• Cuentas de Microsoft
• Microsoft Entra ID (ME-ID)
• Azure Active Directory (AAD) B2C

En los siguientes artículos encontrará más instrucciones de configuración:

• Otros escenarios de seguridad de Blazor WebAssembly en ASP.NET Core
• Uso de Graph API con de ASP.NET CoreBlazor WebAssembly

Uso del flujo de código de autorización con PKCE

La biblioteca de autenticación de Microsoft para JavaScript (MSAL) v2.0 o posterior de la plataforma de identity de Microsoft proporciona compatibilidad para el flujo de código de autorización con la clave de prueba para intercambio de código (PKCE) y el uso compartido de recursos entre orígenes (CORS) para aplicaciones de página única, incluido Blazor.

Microsoft no recomienda usar la concesión implícita.

Para obtener más información, vea los siguientes recursos:

• Compatibilidad con el flujo de autenticación en MSAL: concesión implícita
• Plataforma de identity de Microsoft y flujo de concesión implícita: preferencia por el flujo de código de autenticación
• Flujo de código de autorización de OAuth 2.0 y plataforma de identity de Microsoft

Recursos adicionales

• Documentación de la plataforma de identity de Microsoft
  • Documentación general
  • Tokens de acceso
• Configurar ASP.NET Core para trabajar con servidores proxy y equilibradores de carga
  • Uso de middleware de encabezados reenviados para retener la información de esquemas HTTPS en servidores proxy y redes internas.
  • Escenarios y casos de uso adicionales, incluidos la configuración manual de esquemas, los cambios en las rutas de las solicitudes para corregir el enrutamiento de las solicitudes y el reenvío de esquemas de solicitudes para Linux y proxies inversos que no sean de tipo IIS.
• Representación previa con la autenticación
• WebAssembly: Seguridad
• Especificación de WebAssembly: Consideraciones de seguridad