Partilhar via

Proteger Blazor WebAssembly no ASP.NET Core

  • Artigo

Observação

Esta não é a versão mais recente deste artigo. Para a versão atual, consulte a versão .NET 9 deste artigo.

Aviso

Esta versão do ASP.NET Core não tem mais suporte. Para obter mais informações, confira .NET e a Política de Suporte do .NET Core. Para informações sobre a versão vigente, confira a Versão do .NET 8 deste artigo.

Importante

Essas informações relacionam-se ao produto de pré-lançamento, que poderá ser substancialmente modificado antes do lançamento comercial. A Microsoft não oferece nenhuma garantia, explícita ou implícita, quanto às informações fornecidas aqui.

Para a versão atual, consulte a versão .NET 9 deste artigo.

Aplicativos Blazor WebAssembly são protegidos da mesma maneira que SPAs (aplicativos de página única). Há várias abordagens para autenticar usuários em SPAs, mas a abordagem mais comum e abrangente é usar uma implementação baseada no protocolo OAuth 2.0, como o OIDC (OpenID Connect).

A documentação de segurança Blazor WebAssembly se concentra principalmente em como realizar tarefas de autorização e autenticação do usuário. Para obter a cobertura de conceito geral do OAuth 2.0/OIDC, consulte os recursos na seção Recursos adicionais do artigo de visão geral principal.

Segurança do lado do cliente/SPA de dados e credenciais confidenciais

Uma base de código .NET/C# do aplicativo Blazor WebAssembly é fornecida aos clientes e o código do aplicativo não pode ser protegido contra inspeção e adulteração por parte dos usuários. Nunca coloque credenciais ou segredos em um Blazor WebAssembly aplicativo, como segredos do aplicativo, cadeias de conexão, senhas, código .NET/C# privado ou outros dados confidenciais.

Para proteger o código .NET/C# e usar os recursos da Proteção de Dados do ASP.NET Core para proteger dados, use uma API WEB do ASP.NET Core do lado do servidor. Faça com que o aplicativo Blazor WebAssembly do lado do cliente chame a API Web do lado do servidor para recursos de aplicativo e processamento de dados seguro. Para obter mais informações, consulte Chamar uma API Web de um Blazoraplicativo ASP.NET Core e os artigos neste nó.

Para testes de desenvolvimento local, a ferramenta Gerenciador de segredos é recomendada para proteger dados confidenciais.

Biblioteca de autenticação

Blazor WebAssemblydá suporte à autenticação e autorização de aplicativos usando o OIDC por meio da Microsoft.AspNetCore.Components.WebAssembly.Authentication biblioteca usando a plataforma Microsoftidentity. A biblioteca fornece um conjunto de primitivos para autenticação direta em back-ends do ASP.NET Core. A biblioteca pode se autenticar em qualquer IP (provedor de Identity de terceiros) com suporte para OIDC, que são chamados de OP (Provedores do OpenID).

O suporte à autenticação na Biblioteca Blazor WebAssembly (Authentication.js) é baseado na MSAL (Biblioteca de Autenticação da Microsoft) (msal.js), que é usada para tratar dos detalhes do protocolo de autenticação subjacente. A Biblioteca Blazor WebAssembly só dá suporte ao fluxo de código de autorização de PKCE (Chave de Prova para Troca de Código). Não há suporte para concessão implícita.

Existem outras opções para autenticar SPAs, como o uso de cookies do SameSite. No entanto, o design de engenharia de Blazor WebAssembly usa o OAuth e o OIDC como a melhor opção para autenticação em aplicativos Blazor WebAssembly. A autenticação baseada em token com base em JWTs (Tokens Web JSON) foi escolhida em vez da autenticação baseada em cookie por motivos funcionais e de segurança:

  • O uso de um protocolo baseado em token proporciona menos vulnerabilidades, uma vez que os tokens não são enviados em todas as solicitações.
  • Os pontos de extremidade do servidor não precisam de proteção contra CSRF (solicitação intersite forjada) pois os tokens são enviados de forma explícita ao servidor. Isso permite que você hospede aplicativos Blazor WebAssembly ao lado de aplicativos MVC ou Razor Pages.
  • Os tokens têm permissões mais estreitas que cookies. Por exemplo, tokens não podem ser usados para gerenciar a conta de usuário ou alterar a senha de um usuário a menos que essa funcionalidade seja implementada explicitamente.
  • Os tokens têm um tempo de vida curto, uma hora, o que limita a janela de ataque. Os tokens também podem ser revogados a qualquer momento.
  • JWTs autocontidos oferecem garantias ao cliente e ao servidor sobre o processo de autenticação. Por exemplo, um cliente tem meios para detectar e validar que os tokens recebidos são legítimos e foram emitidos como parte de um determinado processo de autenticação. Se um terceiro tentar trocar um token no meio do processo de autenticação, o cliente poderá detectar o token trocado e evitar usá-lo.
  • Tokens com OAuth e OIDC não dependem do agente de usuário se comportar corretamente para garantir que o aplicativo esteja seguro.
  • Os protocolos baseados em token, como o OAuth e o OIDC, permitem a autenticação e a autorização de usuários em aplicativos Webassembly autônomos Blazor com o mesmo conjunto de características de segurança.
  • O uso de um protocolo baseado em token proporciona menos vulnerabilidades, uma vez que os tokens não são enviados em todas as solicitações.
  • Os pontos de extremidade do servidor não precisam de proteção contra CSRF (solicitação intersite forjada) pois os tokens são enviados de forma explícita ao servidor. Isso permite que você hospede aplicativos Blazor WebAssembly ao lado de aplicativos MVC ou Razor Pages.
  • Os tokens têm permissões mais estreitas que cookies. Por exemplo, tokens não podem ser usados para gerenciar a conta de usuário ou alterar a senha de um usuário a menos que essa funcionalidade seja implementada explicitamente.
  • Os tokens têm um tempo de vida curto, uma hora, o que limita a janela de ataque. Os tokens também podem ser revogados a qualquer momento.
  • JWTs autocontidos oferecem garantias ao cliente e ao servidor sobre o processo de autenticação. Por exemplo, um cliente tem meios para detectar e validar que os tokens recebidos são legítimos e foram emitidos como parte de um determinado processo de autenticação. Se um terceiro tentar trocar um token no meio do processo de autenticação, o cliente poderá detectar o token trocado e evitar usá-lo.
  • Tokens com OAuth e OIDC não dependem do agente de usuário se comportar corretamente para garantir que o aplicativo esteja seguro.
  • Protocolos baseados em token, como OAuth e OIDC, permitem autenticar e autorizar usuários de clientes de solução Blazor WebAssembly hospedados e aplicativos autônomos Blazor Webassembly com o mesmo conjunto de características de segurança.

Importante

Para versões do ASP.NET Core que adotam o Duende Identity Server em modelos de projeto Blazor, o Software Duende pode exigir que você pague uma taxa de licença pelo uso de produção do Duende Identity Server. Para obter mais informações, consulte Migrar do ASP.NET Core 5.0 para o 6.0.

Processo de autenticação com OIDC

A biblioteca Microsoft.AspNetCore.Components.WebAssembly.Authentication oferece vários primitivos para implementar a autenticação e a autorização usando o OIDC. Em termos gerais, a autenticação funciona da seguinte maneira:

  • Quando um usuário anônimo seleciona o botão de logon ou solicita um componente ou página Razor com o atributo [Authorize] aplicado, o usuário é redirecionado para a página de logon do aplicativo (/authentication/login).
  • Na página de logon, a biblioteca de autenticação se prepara para um redirecionamento para o ponto de extremidade de autorização. O ponto de extremidade de autorização está fora do aplicativo Blazor WebAssembly e pode ser hospedado em uma origem separada. O ponto de extremidade é responsável por determinar se o usuário é autenticado e por emitir um ou mais tokens em resposta. A biblioteca de autenticação fornece um retorno de chamada de logon para receber a resposta de autenticação.
    • Se o usuário não for autenticado, ele será redirecionado para o sistema de autenticação subjacente, que geralmente é o ASP.NET Core Identity.
    • Se o usuário já estava autenticado, o ponto de extremidade de autorização gera os tokens apropriados e redireciona o navegador para o ponto de extremidade de retorno de chamada de logon (/authentication/login-callback).
  • Quando o aplicativo Blazor WebAssembly carrega o ponto de extremidade de retorno de chamada de logon (/authentication/login-callback), a resposta de autenticação é processada.
    • Se o processo de autenticação for concluído com êxito, o usuário será autenticado e, opcionalmente, enviado para a URL protegida original solicitada pelo usuário.
    • Se o processo de autenticação falhar por qualquer motivo, o usuário será enviado para a página de falha de logon (/authentication/login-failed), onde um erro será exibido.

componente Authentication

O componente Authentication (Authentication.razor) trata operações de autenticação remota e permite que o aplicativo:

  • Configure rotas de aplicativo para estados de autenticação.
  • Defina conteúdo da interface do usuário para estados de autenticação.
  • Gerencie o estado de autenticação.

Ações de autenticação, como registrar ou conectar um usuário, são passadas para o componente RemoteAuthenticatorViewCore<TAuthenticationState> da estrutura Blazor, que persiste e controla o estado em operações de autenticação.

Para obter mais informações e exemplos, consulte Cenários de segurança adicionais de Blazor WebAssembly no ASP.NET Core.

Autorização

Em aplicativos Blazor WebAssembly, as verificações de autorização podem ser ignoradas porque todos os códigos do lado do cliente podem ser modificados pelos usuários. Isso também ocorre com todas as tecnologias de aplicativo do lado do cliente, incluindo estruturas de SPA do JavaScript ou aplicativos nativos em qualquer sistema operacional.

Sempre execute as verificações de autorização no servidor em qualquer ponto de extremidade da API acessada pelo aplicativo do lado do cliente.

Personalizar a autenticação

O Blazor WebAssembly fornece métodos para adicionar e recuperar parâmetros adicionais para a biblioteca de autenticação subjacente realizar operações de autenticação remota com provedores de identity externos.

Para passar parâmetros adicionais, o NavigationManager dá suporte à passagem e à recuperação do estado de entrada do histórico ao executar alterações de localização externas. Para saber mais, consulte os recursos a seguir:

O estado armazenado pela API de Histórico fornece os seguintes benefícios para a autenticação remota:

  • O estado passado para o ponto de extremidade do aplicativo protegido está vinculado à navegação executada para autenticar o usuário no ponto de extremidade authentication/login.
  • O trabalho adicional de codificar e decodificar dados é evitado.
  • As vulnerabilidades são reduzidas. Ao contrário do que ocorre ao usar a cadeia de caracteres de consulta para armazenar o estado de navegação, uma navegação de nível superior ou influência de uma origem diferente não podem definir o estado armazenado pela API de Histórico.
  • A entrada de histórico é substituída após uma autenticação bem-sucedida, portanto, o estado anexado à entrada de histórico é removido e não requer limpeza.

O InteractiveRequestOptions representa a solicitação ao provedor de identity para fazer logon ou provisionar um token de acesso.

O NavigationManagerExtensions fornece o método NavigateToLogin para uma operação de logon e NavigateToLogout para uma operação de logoff. Os métodos chamam NavigationManager.NavigateTo, definindo o estado de entrada de histórico com um InteractiveRequestOptions passado ou uma instância de InteractiveRequestOptions criada pelo método para:

Os seguintes cenários de autenticação são abordados no artigo Cenários de segurança adicionais do ASP.NET Core Blazor WebAssembly:

  • Personalizar o processo de logon
  • Logoff com uma URL de retorno personalizada
  • Personalizar opções antes de obter um token de modo interativo
  • Personalizar opções ao usar um IAccessTokenProvider
  • Obter o caminho de logon das opções de autenticação

Exigir autorização para todo o aplicativo

Aplique o atributo [Authorize] (documentação da API) a cada componente Razor do aplicativo usando uma das seguintes abordagens:

  • No arquivo Importações do aplicativo, adicione uma diretiva @using para o namespace Microsoft.AspNetCore.Authorization com uma diretiva @attribute para o atributo [Authorize].

    _Imports.razor:

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

    Permitir acesso anônimo ao componente Authentication para permitir o redirecionamento ao provedor de identity. Adicione o código Razor a seguir ao componente Authentication sob sua diretiva @page.

    Authentication.razor:

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

  • Adicione o atributo a cada componente Razor sob a diretiva @page:

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

Observação

Não há suporte para a configuração de um AuthorizationOptions.FallbackPolicy para uma política com RequireAuthenticatedUser.

Usar um registro de aplicativo de provedor de identity por aplicativo

Alguns dos artigos nesta Visão geral referem-se a cenários de hospedagem Blazor que envolvem dois ou mais aplicativos. Um aplicativo autônomo Blazor WebAssembly utiliza a API Web com usuários autenticados para acessar os recursos do servidor e os dados fornecidos por um aplicativo servidor.

Quando esse cenário é implementado nos exemplos da documentação, são utilizados dois registros de provedores de identity, um para o aplicativo cliente e outro para o aplicativo servidor. O uso de registros separados, por exemplo, no Microsoft Entra ID, não é estritamente necessário. No entanto, o uso de dois registros é uma prática recomendada de segurança porque isola os registros por aplicativo. O uso de registros separados também permite a configuração independente dos registros de cliente e servidor.

Alguns artigos nesta Visão geral referem-se a qualquer um dos seguintes cenários de hospedagem Blazor que envolvem dois ou mais aplicativos:

  • Uma solução hospedada Blazor WebAssembly, composta por dois aplicativos: um aplicativo do lado do cliente Blazor WebAssembly e um aplicativo host do lado do servidor ASP.NET Core. Os usuários autenticados no aplicativo cliente acessam os recursos do servidor e os dados fornecidos pelo aplicativo do servidor.
  • Um aplicativo autônomo Blazor WebAssembly que usa a API Web com usuários autenticados para acessar os recursos do servidor e os dados fornecidos por um aplicativo de servidor. Esse cenário é semelhante ao uso de uma solução hospedada Blazor WebAssembly; mas, nesse caso, o aplicativo cliente não é hospedado pelo aplicativo do servidor.

Quando esses cenários são implementados em exemplos de documentação, dois registros de provedor de identity são usados, um para o aplicativo cliente e outro para o aplicativo de servidor. O uso de registros separados, por exemplo, no Microsoft Entra ID, não é estritamente necessário. No entanto, o uso de dois registros é uma prática recomendada de segurança porque isola os registros por aplicativo. O uso de registros separados também permite a configuração independente dos registros de cliente e servidor.

Tokens de atualização

Embora os tokens de atualização não possam ser protegidos em aplicativos Blazor WebAssembly, eles podem ser usados se você implementá-los com estratégias de segurança apropriadas.

No caso de aplicativos Blazor WebAssembly autônomos do ASP.NET Core no .NET 6 ou posterior, recomendamos usar:

Para soluções Blazor WebAssembly hospedadas, os tokens de atualização podem ser mantidos e usados pelo aplicativo do lado do servidor para acessar APIs de terceiros. Para obter mais informações, consulte Cenários de segurança adicionais de Blazor WebAssembly no ASP.NET Core.

Para saber mais, consulte os recursos a seguir:

Estabelecer declarações para usuários

Os aplicativos geralmente exigem declarações para usuários com base em uma chamada à API Web para um servidor. Por exemplo, as declarações frequentemente são usadas para estabelecer autorização em um aplicativo. Nesses cenários, o aplicativo solicita um token de acesso para acessar o serviço e usa o token para obter os dados do usuário para criar declarações.

Para ver exemplos, consulte os seguintes recursos:

Suporte pré-geração

Não há suporte para pré-renderização para pontos de extremidade de autenticação (segmento de linha /authentication/).

Não há suporte para pré-renderização para pontos de extremidade de autenticação (segmento de linha /authentication/).

Para obter mais informações, consulte Cenários de segurança adicionais de Blazor WebAssembly no ASP.NET Core.

Serviço de Aplicativo do Azure no Linux com o Identity Server

Especifique o emissor explicitamente ao implantar no Serviço de Aplicativo do Azure no Linux com o Identity Server.

Para obter mais informações, confira Usar o Identity para proteger um back-end da API Web para SPAs.

Autenticação do Windows

Não recomendamos usar a Autenticação do Windows com Blazor Webassembly ou com qualquer outra estrutura de SPA. É recomendável usar protocolos baseados em token em vez da Autenticação do Windows, como o OIDC com o ADFS (Serviços de Federação do Active Directory).

Se a Autenticação do Windows for usada com o Webassembly Blazor ou com qualquer outra estrutura de SPA, medidas adicionais serão necessárias para proteger o aplicativo contra tokens CSRF (solicitação intersite forjada). As mesmas preocupações que se aplicam a cookies se aplicam à Autenticação do Windows; além disso, a Autenticação do Windows não oferece um mecanismo para impedir o compartilhamento do contexto de autenticação entre origens. Aplicativos que usam a Autenticação do Windows sem proteção adicional do CSRF devem pelo menos ser restritos à intranet de uma organização e não serem usados na Internet.

Para obter mais informações, consulte Impedir ataques de XSRF/CSRF (solicitação intersite forjada) no ASP.NET Core.

Assegure um hub SignalR

Para proteger um hub SignalR no projeto de API do servidor, aplique o atributo [Authorize] à classe do hub ou aos métodos da classe do hub.

Em um projeto do cliente com pré-renderização, como Blazor WebAssembly hospedado (ASP.NET Core no .NET 7 ou mais antigo) ou ume Blazor Web App (ASP.NET Core no .NET 8 ou mais recente), consulte as diretrizes em Diretrizes do ASP.NET Core BlazorSignalR.

Em um componente de projeto do cliente sem pré-renderização, como aplicativos autônomos Blazor WebAssembly ou não navegadores, forneça um token de acesso para a conexão do hub, como demonstra o exemplo a seguir. Para obter mais informações, confira Autenticação e autorização no ASP.NET CoreSignalR.

@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();

  ...
}

Logging

Esta seção se aplica aos aplicativos Blazor WebAssembly do ASP.NET Core no .NET 7 ou posterior.

Para habilitar o log de depuração ou rastreamento, consulte a seção Registro em log de autenticação (Blazor WebAssembly) em uma versão 7.0 ou posterior do artigo Registro em log Blazor do ASP.NET Core.

A área restrita do WebAssembly

A área restrita do WebAssembly restringe o acesso ao ambiente do sistema que executa o código WebAssembly, incluindo acesso a subsistemas de E/S, armazenamento e recursos do sistema e ao sistema operacional. O isolamento entre o código do WebAssembly e o sistema que executa o código, torna o WebAssembly uma estrutura de codificação segura para sistemas. No entanto, o WebAssembly é vulnerável a ataques de temporização no nível do hardware. As precauções normais e a devida diligência no fornecimento de hardware e na colocação de limitações no acesso ao hardware se aplicam.

O WebAssembly não é de propriedade ou mantido pela Microsoft.

Para obter mais informações, consulte os seguintes recursos do W3C:

Diretrizes de implementação

Os artigos nesta Visão geral fornecem informações sobre como autenticar usuários em aplicativos Blazor WebAssembly em provedores específicos.

Aplicativos Blazor WebAssembly autônomos:

Outras diretrizes de configuração são encontradas nos seguintes artigos:

Usar o fluxo de Código de Autorização com PKCE

A MSAL (Biblioteca de Autenticação da Microsoft) para JavaScript v2.0 ou mais recente da plataforma de identity da Microsoft fornece suporte para o fluxo de Código de Autorização com PKCE (Chave de Prova para Troca de Código) e CORS (Compartilhamento de Recursos entre Origens) para aplicativos de página única, incluindo Blazor.

A Microsoft não recomenda usar a Concessão implícita.

Para saber mais, consulte os recursos a seguir:

Recursos adicionais