Protección de ASP.NET Core Blazor WebAssembly

  • Artículo

Nota

Esta no es la versión más reciente de este artículo. Para la versión actual, consulte la versión .NET 8 de este artículo.

Importante

Esta información hace referencia a un producto en versión preliminar, el cual puede sufrir importantes modificaciones antes de que se publique la versión comercial. Microsoft no proporciona ninguna garantía, expresa o implícita, con respecto a la información proporcionada aquí.

Para la versión actual, consulte la versión .NET 8 de este artículo.

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

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 nada de naturaleza secreta en una aplicación Blazor WebAssembly, como código .NET/C# privado, claves de seguridad, contraseñas o cualquier otro tipo de información confidencial.

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.

Biblioteca de autenticación

Blazor WebAssembly admite la autenticación y autorización de aplicaciones mediante OIDC a través de la biblioteca Microsoft.AspNetCore.Components.WebAssembly.Authentication usando Microsoft Identity Platform. 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 una superficie expuesta a ataques más pequeña, ya que los tokens no se envían en todas las solicitudes.
  • Los puntos de conexión de servidor no requieren protección contra la Falsificación de solicitudes entre sitios (CSRF), ya que los tokens se envían de forma explícita. 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 de forma predeterminada, 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.
  • El uso de un protocolo basado en tokens ofrece una superficie expuesta a ataques más pequeña, ya que los tokens no se envían en todas las solicitudes.
  • Los puntos de conexión de servidor no requieren protección contra la Falsificación de solicitudes entre sitios (CSRF), ya que los tokens se envían de forma explícita. 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 de forma predeterminada, 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 tokens, como OAuth y OIDC, permiten autenticar y autorizar a los usuarios de los clientes de la solución Blazor WebAssembly hospedados y las 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 identidades 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:

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 reduce el área expuesta a ataques. 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 identidades 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:

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 identidades. 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 identidades 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 identidades, 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.

Algunos de los artículos de esta información general pertenecen a cualquiera de los siguientes escenarios de hospedaje de Blazor que implican dos o más aplicaciones:

  • una solución de Blazor WebAssembly hospedada, que se compone de dos aplicaciones, una aplicación Blazor WebAssembly del lado cliente y una aplicación host de ASP.NET Core del lado servidor. Los usuarios autenticados en la aplicación cliente acceden a los recursos del servidor y a los datos proporcionados por la aplicación de servidor.
  • Una aplicación independiente Blazor WebAssembly que 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. Este escenario es similar al uso de una solución de Blazor WebAssembly hospedada; pero, en este caso, la aplicación de servidor no hospeda la aplicación cliente.

Cuando estos escenarios se implementan en ejemplos de documentación, se usan dos registros del proveedor de identidades, 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:

Para las soluciones de Blazor WebAssembly hospedadas, los tokens de actualización se pueden mantener y usar en la aplicación del lado servidor para acceder a las API de terceros. Para más información, vea Escenarios de seguridad adicionales de Blazor WebAssembly en ASP.NET Core.

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

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:

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/).

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 posterior) o una aplicación web Blazor (ASP.NET Core en .NET 8 o una versión posterior), consulte 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:

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:

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

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 identidad 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:

Recursos adicionales