Autenticação e autorização do ASP.NET Core Blazor

Este artigo descreve o suporte do ASP.NET Core para a configuração e o gerenciamento de segurança em aplicativos Blazor.

Blazor usa os mecanismos de autenticação existentes do ASP.NET Core para estabelecer a identitydo utilizador. O mecanismo exato depende de como o aplicativo Blazor está hospedado, do lado do servidor ou do lado do cliente.

Os cenários de segurança diferem entre o código de autorização executado no lado do servidor e no lado do cliente em aplicativos Blazor. Para o código de autorização executado no servidor, as verificações de autorização podem impor regras de acesso para áreas do aplicativo e componentes. Como a execução de código do lado do cliente pode ser adulterada, não se pode confiar no código de autorização executado no cliente para impor absolutamente as regras de acesso ou controlar a exibição de conteúdo do lado do cliente.

Se a aplicação da regra de autorização precisar ser garantida, não implemente verificações de autorização no código do lado do cliente. Crie um Blazor Web App que confie unicamente na renderização do lado do servidor (SSR) para verificações de autorização e aplicação de regras.

Razor As convenções de autorização do Pages não se aplicam a componentes de Razor roteáveis. Se um componente Razor não roteável estiver incorporado em uma página de um aplicativo Razor Páginas, as convenções de autorização da página afetarão indiretamente o componente Razor juntamente com a rest do conteúdo da página.

Observação

Os exemplos de código neste artigo adotam tipos de referência anuláveis (NRTs) ede análise estática de estado nulo do compilador .NET, que são suportados no ASP.NET Core no .NET 6 ou posterior. Ao trabalhar com o ASP.NET Core 5.0 ou anterior, remova a designação de tipo nulo (?) dos exemplos deste artigo.

Mantenha dados e credenciais confidenciais com segurança

Não armazene segredos de aplicativos, cadeias de conexão, credenciais, senhas, números de identificação pessoal (PINs), código .NET/C# privado ou chaves/tokens privados no código do lado do cliente, que é sempre inseguro. O código Blazor do lado do cliente deve acessar serviços e bancos de dados seguros por meio de uma API da Web segura que você controla.

Em ambientes de teste/preparação e produção, o código Blazor do lado do servidor e as APIs da Web devem usar fluxos de autenticação seguros que evitem a manutenção de credenciais no código do projeto ou nos arquivos de configuração. Fora dos testes de desenvolvimento local, recomendamos evitar o uso de variáveis de ambiente para armazenar dados confidenciais, pois as variáveis de ambiente não são a abordagem mais segura. Para testes de desenvolvimento local, a ferramenta Secret Manager é recomendada para proteger dados confidenciais. Para obter mais informações, consulte os seguintes recursos:

• Fluxos de autenticação seguros (documentação ASP.NET Core)
• Identidades gerenciadas para serviços do Microsoft Azure (este artigo)

Para desenvolvimento e testes locais do lado do cliente e do servidor, use a ferramenta Secret Manager para proteger credenciais confidenciais.

Identidades gerenciadas para serviços do Microsoft Azure

Para serviços do Microsoft Azure, recomendamos o uso de identidades gerenciadas . As identidades gerenciadas são autenticadas com segurança nos serviços do Azure sem armazenar credenciais no código do aplicativo. Para obter mais informações, consulte os seguintes recursos:

• O que são identidades gerenciadas para recursos do Azure? (Documentação do Microsoft Entra)
• Documentação dos serviços do Azure
  • Identidades geridas no Microsoft Entra para SQL do Azure
  • Como usar identidades gerenciadas para o Serviço de Aplicativo e o Azure Functions

Suporte antifalsificação

O modelo Blazor:

• Adiciona serviços antifalsificação automaticamente quando AddRazorComponents é chamado no arquivo Program.
• Adiciona o Antiforgery Middleware chamando UseAntiforgery na sua pipeline de processamento de pedidos no arquivo Program e requisita proteção antifalsificação no endpoint com para mitigar as ameaças de falsificação de pedidos entre sites (CSRF/XSRF). UseAntiforgery é chamado após UseHttpsRedirection. Uma chamada para UseAntiforgery deve ser feita após chamadas, se houver, para UseAuthentication e UseAuthorization.

O componente AntiforgeryToken renderiza um token antifalsificação como um campo oculto, e esse componente é adicionado automaticamente às instâncias de formulário (EditForm). Para obter mais informações, consulte Visão geral dos formulários do ASP.NET Core Blazor.

O serviço AntiforgeryStateProvider fornece acesso a um token antifalsificação associado à sessão atual. Injete o serviço e chame seu método GetAntiforgeryToken() para obter o AntiforgeryRequestTokenatual. Para mais informações, consulte Chamar uma API da Web a partir de uma aplicação ASP.NET Core Blazor.

Blazor armazena tokens de solicitação no estado do componente, o que garante que os tokens antifalsificação estejam disponíveis para componentes interativos, mesmo quando eles não têm acesso à solicitação.

Observação

de mitigação antifalsificação só é necessária ao enviar dados de formulário para o servidor codificado como application/x-www-form-urlencoded, multipart/form-dataou text/plain uma vez que estes são os únicos formulários válidos.

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

• Prevenir ataques de falsificação de solicitação entre sites (XSRF/CSRF) em ASP.NETprincipal: Este artigo é o principal artigo ASP.NET Core sobre o assunto, que se aplica ao Blazor Serverdo lado do servidor, ao projeto de servidor do Blazor Web Apps e à integração Blazor com o MVC /Razor Pages.
• ASP.NET Core Visão geral dos formulários: A secção de suporte a antifalsificação do artigo refere-se ao suporte antifalsificação de formulários .

Autenticação de Blazor do lado do servidor

Os aplicativos Blazor do lado do servidor são configurados para segurança da mesma maneira que os aplicativos ASP.NET Core. Para obter mais informações, consulte os artigos em tópicos de segurança do ASP.NET Core.

O contexto de autenticação só é estabelecido quando o aplicativo é iniciado, que é quando o aplicativo se conecta pela primeira vez ao WebSocket por meio de um de conexão SignalR com o cliente. A autenticação pode ser baseada em um cookie ou em algum outro token de portador, mas a autenticação é gerenciada através do hub SignalR e inteiramente dentro do circuito . O contexto de autenticação é mantido durante o tempo de vida do circuito. Os aplicativos revalidam periodicamente o estado de autenticação do usuário a cada 30 minutos.

Se a aplicação precisar capturar usuários para serviços personalizados ou reagir a atualizações do usuário, consulte ASP.NET Core do lado do servidor e Blazor Web App cenários adicionais de segurança.

Blazor difere de aplicações web renderizadas no lado do servidor tradicionais que fazem novas solicitações HTTP com cookies a cada navegação de página. A autenticação é verificada durante eventos de navegação. No entanto, os cookies não estão envolvidos. Os cookies só são enviados quando se faz um pedido HTTP a um servidor, o que não acontece quando o utilizador navega numa aplicação Blazor. Durante a navegação, o estado de autenticação do usuário é verificado dentro do circuito Blazor, que pode ser atualizado a qualquer momento no servidor usando o RevalidatingAuthenticationStateProvider abstração.

Importante

A implementação de um NavigationManager personalizado para obter a validação de autenticação durante a navegação não é recomendada. Se a aplicação precisar executar uma lógica personalizada de estado de autenticação durante a navegação, use um AuthenticationStateProviderpersonalizado.

Observação

Os exemplos de código neste artigo adotam tipos de referência anuláveis (NRTs) ede análise estática de estado nulo do compilador .NET, que são suportados no ASP.NET Core no .NET 6 ou posterior. Ao direcionar para o ASP.NET Core 5.0 ou versões anteriores, remova a atribuição de tipo nulo (?) dos exemplos neste artigo.

O serviço de AuthenticationStateProvider interno ou personalizado obtém dados de estado de autenticação do HttpContext.Userdo ASP.NET Core. É assim que o estado de autenticação se integra aos mecanismos de autenticação ASP.NET Core existentes.

Para obter mais informações sobre a autenticação no servidor, consulte ASP.NET Core Blazor authentication and authorization.

IHttpContextAccessor / HttpContext em componentes Razor

IHttpContextAccessor deve ser evitado com a renderização interativa porque não há um HttpContext válido disponível.

IHttpContextAccessor pode ser usado para componentes que são renderizados estaticamente no servidor. No entanto, recomendamos evitá-lo, se possível.

HttpContext pode ser usado como um parâmetro em cascata somente em componentes raiz renderizados estaticamente para tarefas gerais, como inspecionar e modificar cabeçalhos ou outras propriedades no componente App (Components/App.razor). O valor é sempre null para renderização interativa.

[CascadingParameter]
public HttpContext? HttpContext { get; set; }

Para cenários em que o HttpContext seja necessário em componentes interativos, recomendamos a transferência dos dados através do estado persistente do componente do servidor. Para obter mais informações, consulte ASP.NET Core do lado do servidor e Blazor Web App cenários de segurança adicionais.

Estado compartilhado

Os aplicativos Blazor do lado do servidor vivem na memória do servidor e várias sessões de aplicativos são hospedadas no mesmo processo. Para cada sessão de aplicativo, Blazor inicia um circuito com um escopo próprio de contêiner de injeção de dependências, portanto, os serviços de escopo são exclusivos por sessão de Blazor.

Advertência

Não recomendamos que aplicações no mesmo servidor partilhem estado usando serviços singleton, a menos que seja tomado extremo cuidado, pois isso pode introduzir vulnerabilidades de segurança, como a divulgação do estado do utilizador entre circuitos.

Você pode usar serviços singleton com estado em aplicações Blazor se forem projetados especificamente para isso. Por exemplo, o uso de um cache de memória singleton é aceitável porque um cache de memória requer uma chave para acessar uma determinada entrada. Supondo que os usuários não tenham controle sobre as chaves de cache usadas com o cache, o estado armazenado no cache não vaza entre circuitos.

Para obter orientações gerais sobre a gestão do Estado, consulte ASP.NET Core Blazor State Management.

Segurança do lado do servidor de dados e credenciais confidenciais

Em ambientes de teste/preparação e produção, o código Blazor do lado do servidor e as APIs da Web devem usar fluxos de autenticação seguros que evitem a manutenção de credenciais no código do projeto ou nos arquivos de configuração. Fora dos testes de desenvolvimento local, recomendamos evitar o uso de variáveis de ambiente para armazenar dados confidenciais, pois as variáveis de ambiente não são a abordagem mais segura. Para testes de desenvolvimento local, a ferramenta Secret Manager é recomendada para proteger dados confidenciais. Para obter mais informações, consulte os seguintes recursos:

• Fluxos de autenticação seguros (documentação ASP.NET Core)
• Identidades gerenciadas para serviços do Microsoft Azure (Blazor documentação)

Para desenvolvimento e testes locais do lado do cliente e do servidor, use a ferramenta Secret Manager para proteger credenciais confidenciais.

Modelo de projeto

Crie um novo aplicativo Blazor do lado do servidor seguindo as orientações em Tooling for ASP.NET Core Blazor.

Visual Studio

Depois de escolher o modelo de aplicativo do lado do servidor e configurar o projeto, selecione a autenticação do aplicativo em Tipo de autenticação:

• Nenhum (padrão): Sem autenticação.
• Contas individuais: As contas de usuário são armazenadas no aplicativo usando ASP.NET Core Identity.

Ao emitir o comando .NET CLI para criar e configurar o aplicativo Blazor do lado do servidor, indique o mecanismo de autenticação com a opção -au|--auth:

-au {AUTHENTICATION}

Observação

Para obter o comando completo, consulte Tooling for ASP.NET Core Blazor.

Os valores de autenticação permitidos para o marcador de posição {AUTHENTICATION} são apresentados na tabela seguinte.

Mecanismo de autenticação	Descrição
None (padrão)	Sem autenticação
Individual	Usuários armazenados no aplicativo com ASP.NET Core Identity

Para obter mais informações, consulte o comando dotnet new no Guia do .NET Core.

Ao emitir o comando .NET CLI para criar e configurar o aplicativo Blazor do lado do servidor, indique o mecanismo de autenticação com a opção -au|--auth:

-au {AUTHENTICATION}

Observação

Para obter o comando completo, consulte Tooling for ASP.NET Core Blazor.

Os valores de autenticação permitidos para o espaço reservado {AUTHENTICATION} são mostrados na tabela a seguir.

Mecanismo de autenticação	Descrição
None (padrão)	Sem autenticação
Individual	Usuários armazenados no aplicativo com ASP.NET Core Identity

Para mais informações:

• Consulte o comando dotnet new no Guia do .NET Core.

• Execute o comando help para o modelo em um shell de comando:

  dotnet new {PROJECT TEMPLATE} --help
  

  No comando anterior, o marcador de posição {PROJECT TEMPLATE} é o modelo de projeto.

Blazor Identity UI (Contas Individuais)

Blazor oferece suporte à geração de uma interface do usuário Identity baseada em Blazorcompleta quando você escolhe a opção de autenticação para Contas Individuais.

O modelo Blazor Web App serve de estrutura para o código Identity de um banco de dados de SQL Server. A versão de linha de comando usa SQLite e inclui um banco de dados SQLite para Identity.

O modelo:

• Suporta cenários interativos de renderização do lado do servidor (SSR interativo) e CSR (renderização do lado do cliente) com usuários autenticados.
• Adiciona componentes IdentityRazor e lógica relacionada para tarefas de autenticação de rotina, como entrar e sair de usuários. Os componentes Identity também suportam recursos avançados de Identity, como confirmação de conta e recuperação de senha e autenticação multifator usando um aplicativo de terceiros. Observe que os próprios componentes Identity não suportam interatividade.
• Adiciona os pacotes e dependências relacionados ao Identity.
• Faz referência aos pacotes Identity em _Imports.razor.
• Cria uma classe de usuário Identity personalizada (ApplicationUser).
• Cria e registra um contexto de banco de dados EF Core (ApplicationDbContext).
• Configura o roteamento para as extremidades integradas de Identity.
• Inclui validação Identity e lógica de negócios.

Para inspecionar os componentes Identity da estrutura Blazor, acesse-os nas pastas Pages e Shared da pasta Account no modelo de projeto Blazor Web App (fonte de referência).

Quando você escolhe os modos de renderização Interactive WebAssembly ou Interactive Auto, o servidor lida com todas as solicitações de autenticação e autorização, e os componentes Identity renderizam estaticamente no servidor no projeto principal do Blazor Web App.

O framework fornece uma AuthenticationStateProvider personalizada nos projetos de servidor e cliente (.Client) de modo a transmitir o estado de autenticação do utilizador para o navegador. O projeto de servidor chama AddAuthenticationStateSerialization, enquanto o projeto cliente chama AddAuthenticationStateDeserialization. A autenticação no servidor em vez do cliente permite que o aplicativo acesse o estado de autenticação durante a pré-renderização e antes que o tempo de execução do .NET WebAssembly seja inicializado. As implementações personalizadas de AuthenticationStateProvider usam o serviço de Estado de Componente Persistente (PersistentComponentState) para serializar o estado de autenticação em comentários HTML e para depois lê-lo de volta do WebAssembly, criando assim uma nova instância de AuthenticationState. Para obter mais informações, consulte a seção Gerenciar estado de autenticação no do Blazor Web App.

Somente para soluções de servidor interativo, IdentityRevalidatingAuthenticationStateProvider (fonte de referência) é um AuthenticationStateProvider do lado do servidor que revalida o carimbo de segurança para o utilizador conectado a cada 30 minutos, enquanto um circuito interativo está conectado.

Blazor Identity depende de instâncias DbContext que não são criadas por umde fábrica, o que é intencional porque DbContext é suficiente para que os componentes Identity do modelo de projeto sejam renderizados estaticamente sem suporte à interatividade.

Para obter uma descrição sobre como os modos de renderização interativos globais são aplicados a componentes nãoIdentity e, ao mesmo tempo, impõem SSR estático para os componentes Identity, consulte modos de renderização do ASP.NET Core Blazor.

Para obter mais informações sobre a persistência do estado pré-renderizado, consulte componentes pré-renderizados do ASP.NET Core Razor.

Observação

Os links de documentação para a fonte de referência do .NET geralmente carregam a ramificação padrão do repositório, que representa o desenvolvimento atual para a próxima versão do .NET. Para selecionar uma etiqueta para uma versão específica, use a lista suspensa Mudar ramificações ou etiquetas. Para obter mais informações, consulte Como selecionar uma marca de versão do código-fonte do ASP.NET Core (dotnet/AspNetCore.Docs #26205).

Gerenciar o estado de autenticação no Blazor Web Apps

Esta secção aplica-se aos Blazor Web Appque adotam:

• Contas individuais
• Renderização do lado do cliente (CSR, interatividade suportada por WebAssembly).

Um provedor de estado de autenticação do lado do cliente é usado apenas dentro do Blazor e não está integrado ao sistema de autenticação ASP.NET Core. Durante a pré-renderização, Blazor respeita os metadados definidos na página e usa o sistema de autenticação ASP.NET Core para determinar se o usuário está autenticado. Quando um usuário navega de uma página para outra, um provedor de autenticação do lado do cliente é usado. Quando o usuário atualiza a página (recarga de página inteira), o provedor de estado de autenticação do lado do cliente não está envolvido na decisão de autenticação no servidor. Como o estado do usuário não é persistido pelo servidor, qualquer estado de autenticação mantido no lado do cliente é perdido.

Para resolver isso, a melhor abordagem é executar a autenticação dentro do sistema de autenticação ASP.NET Core. O provedor de estado de autenticação do lado do cliente cuida apenas de refletir o estado de autenticação do usuário. Exemplos de como fazer isso com provedores de estado de autenticação são demonstrados pelo modelo de projeto Blazor Web App e descritos abaixo.

No arquivo do projeto de servidor, chame , que serializa o retornado pelo do lado do servidor usando o de serviço Persistent Component State ():

builder.Services.AddRazorComponents()
    .AddInteractiveWebAssemblyComponents()
    .AddAuthenticationStateSerialization();

A API serializa apenas o nome do lado do servidor e as declarações de função para acesso no navegador. Para incluir todas as declarações, defina SerializeAllClaims como true na chamada do lado do servidor para AddAuthenticationStateSerialization:

builder.Services.AddRazorComponents()
    .AddInteractiveWebAssemblyComponents()
    .AddAuthenticationStateSerialization(
        options => options.SerializeAllClaims = true);

No arquivo Program do projeto cliente (.Client), chame AddAuthenticationStateDeserialization, que adiciona um AuthenticationStateProvider onde o AuthenticationState é desserializado do servidor usando AuthenticationStateData e o serviço de Estado de Componente Persistente (PersistentComponentState). Deve haver uma chamada correspondente para AddAuthenticationStateSerialization no projeto de servidor.

builder.Services.AddAuthorizationCore();
builder.Services.AddCascadingAuthenticationState();
builder.Services.AddAuthenticationStateDeserialization();

Reivindicações e tokens adicionais de fornecedores externos

Para armazenar declarações adicionais de provedores externos, consulte Persistir declarações e tokens adicionais de provedores externos no ASP.NET Core.

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

Especifique o emissor explicitamente ao implementar no App Service do Azure no Linux com o Servidor Identity. Para obter mais informações, consulte Usar Identity para proteger um back-end de API da Web para SPAs.

Injetar AuthenticationStateProvider para serviços com escopo de um componente

Não tente resolver AuthenticationStateProvider dentro de um escopo personalizado porque isso resulta na criação de uma nova instância do AuthenticationStateProvider que não foi inicializada corretamente.

Para aceder o AuthenticationStateProvider dentro de um serviço com âmbito definido para um componente, injete o AuthenticationStateProvider com a diretiva @inject ou com o atributo [Inject] e passe-o para o serviço como um parâmetro. Essa abordagem garante que a instância correta e inicializada do AuthenticationStateProvider seja usada para cada instância do aplicativo do usuário.

ExampleService.cs:

public class ExampleService
{
    public async Task<string> ExampleMethod(AuthenticationStateProvider authStateProvider)
    {
        var authState = await authStateProvider.GetAuthenticationStateAsync();
        var user = authState.User;

        if (user.Identity is not null && user.Identity.IsAuthenticated)
        {
            return $"{user.Identity.Name} is authenticated.";
        }
        else
        {
            return "The user is NOT authenticated.";
        }
    }
}

Registre o serviço como escopo. Em uma aplicação Blazor do lado do servidor, os serviços com escopo têm um tempo de vida igual à duração do circuito de conexão do cliente .

No ficheiro Program:

builder.Services.AddScoped<ExampleService>();

No seguinte componente InjectAuthStateProvider:

• O componente herda OwningComponentBase.
• O AuthenticationStateProvider é injetado e passado para ExampleService.ExampleMethod.
• ExampleService é resolvido com OwningComponentBase.ScopedServices e GetRequiredService, que retorna a instância correta e inicializada de ExampleService que existe ao longo do tempo de vida do circuito do usuário.

InjectAuthStateProvider.razor:

@page "/inject-auth-state-provider"
@inherits OwningComponentBase
@inject AuthenticationStateProvider AuthenticationStateProvider

<h1>Inject <code>AuthenticationStateProvider</code> Example</h1>

<p>@message</p>

@code {
    private string? message;
    private ExampleService? ExampleService { get; set; }

    protected override async Task OnInitializedAsync()
    {
        ExampleService = ScopedServices.GetRequiredService<ExampleService>();

        message = await ExampleService.ExampleMethod(AuthenticationStateProvider);
    }
}

Para obter mais informações, consulte as orientações sobre OwningComponentBase em injeção de dependência do ASP.NET Core Blazor.

Exibição de conteúdo não autorizado durante a pré-renderização com um AuthenticationStateProvider personalizado

Para evitar mostrar conteúdo não autorizado, por exemplo, conteúdo em um componente AuthorizeView, durante a pré-renderização com um AuthenticationStateProviderpersonalizado, adote uma das seguintes abordagens:

• Implementar IHostEnvironmentAuthenticationStateProvider para o AuthenticationStateProvider personalizado para dar suporte à pré-renderização: Para obter um exemplo de implementação de IHostEnvironmentAuthenticationStateProvider, consulte a implementação ServerAuthenticationStateProvider da estrutura de Blazor em ServerAuthenticationStateProvider.cs (fonte de referência).

  Observação

  Os links de documentação para a fonte de referência do .NET geralmente carregam a ramificação padrão do repositório, que representa o desenvolvimento atual para a próxima versão do .NET. Para selecionar uma tag para uma versão específica, use a lista suspensa Trocar entre ramificações ou tags. Para obter mais informações, consulte Como selecionar uma marca de versão do código-fonte do ASP.NET Core (dotnet/AspNetCore.Docs #26205).

• Desativar pré-renderização: indique o modo de renderização com o parâmetro prerender definido como false no componente de nível mais alto na hierarquia de componentes do aplicativo que não seja um componente raiz.

  Observação

  Não há suporte para tornar um componente raiz interativo, como o componente App. Portanto, a pré-renderização não pode ser desabilitada diretamente pelo componente App.

  Para aplicativos baseados no modelo de projeto Blazor Web App, a pré-renderização normalmente é desabilitada quando o componente Routes é usado no componente App (Components/App.razor) :

  <Routes @rendermode="new InteractiveServerRenderMode(prerender: false)" />
  

  Além disso, desative a pré-renderização para o componente HeadOutlet:

  <HeadOutlet @rendermode="new InteractiveServerRenderMode(prerender: false)" />
  

  Você também pode controlar seletivamente o modo de renderização aplicado à instância do componente Routes. Por exemplo, consulte os modos de renderização do ASP.NET Core Blazor.

• Autenticar o utilizador no servidor antes de a aplicação ser iniciada: para adotar esta abordagem, a aplicação deve responder à solicitação inicial de um utilizador com a página ou a vista de início de sessão baseada em Identitye impedir quaisquer solicitações para pontos de extremidade Blazor até que sejam autenticados. Para obter mais informações, consulte Criar um aplicativo ASP.NET Core com dados do usuário protegidos por autorização. Após a autenticação, o conteúdo não autorizado em componentes Razor pré-renderizados só é mostrado quando o usuário está realmente não autorizado a visualizar o conteúdo.

Gerenciamento de estado do usuário

Apesar da palavra "estado" no nome, AuthenticationStateProvider não é para armazenar estado geral do usuário. AuthenticationStateProvider indica apenas o estado de autenticação do usuário para o aplicativo, se ele está conectado ao aplicativo e com quem está conectado.

A autenticação usa a mesma autenticação ASP.NET Core Identity que os aplicativos Razor Pages e MVC. O estado do usuário armazenado para ASP.NET Core Identity flui para Blazor sem adicionar código adicional ao aplicativo. Siga as orientações nos artigos e tutoriais do ASP.NET Core Identity para que os recursos de Identity entrem em vigor nas partes Blazor do aplicativo.

Para obter orientações sobre gestão geral de estado fora do ASP.NET Core Identity, consulte gestão de estado no ASP.NET Core Blazor.

Abstrações de segurança adicionais

Duas abstrações adicionais participam do gerenciamento do estado de autenticação:

• ServerAuthenticationStateProvider (fonte de referência): Um AuthenticationStateProvider usado pela estrutura Blazor para obter o estado de autenticação do servidor.

• RevalidatingServerAuthenticationStateProvider (fonte de referência): Uma classe base para serviços de AuthenticationStateProvider usados pela estrutura Blazor para receber um estado de autenticação do ambiente host e revalidá-lo em intervalos regulares.

  O intervalo de revalidação padrão de 30 minutos pode ser ajustado em RevalidatingIdentityAuthenticationStateProvider (Areas/Identity/RevalidatingIdentityAuthenticationStateProvider.cs). O exemplo a seguir reduz o intervalo para 20 minutos:

  protected override TimeSpan RevalidationInterval => TimeSpan.FromMinutes(20);
  

Observação

Os links de documentação para a fonte de referência do .NET geralmente carregam a ramificação padrão do repositório, que representa o desenvolvimento atual para a próxima versão do .NET. Para selecionar uma tag para uma versão específica, use a lista suspensa Mudar ramificações ou tags. Para obter mais informações, consulte Como selecionar uma marca de versão do código-fonte do ASP.NET Core (dotnet/AspNetCore.Docs #26205).

Gerenciamento de estado de autenticação ao sair

O Blazor do lado do servidor persiste o estado de autenticação do usuário durante o tempo de vida do circuito, inclusive nas guias do navegador. Para desconectar proativamente um utilizador nas guias do navegador quando o utilizador sair de uma guia, deve implementar um RevalidatingServerAuthenticationStateProvider (fonte de referência) com um RevalidationIntervalcurto.

Observação

Os links de documentação para a fonte de referência do .NET geralmente carregam a ramificação padrão do repositório, que representa o desenvolvimento atual para a próxima versão do .NET. Para selecionar uma tag para uma versão específica, use a lista suspensa Alternar ramificações ou tags. Para obter mais informações, consulte Como selecionar uma marca de versão do código-fonte do ASP.NET Core (dotnet/AspNetCore.Docs #26205).

Duração da validade do URL de redirecionamento temporário

Esta secção aplica-se a Blazor Web Apps.

Use a opção RazorComponentsServiceOptions.TemporaryRedirectionUrlValidityDuration para obter ou definir o tempo de vida da validade do ASP.NET Core Data Protection para URLs de redirecionamento temporário emitidas pela renderização do lado do servidor Blazor. Eles são usados apenas transitoriamente, então o tempo de vida só precisa ser longo o suficiente para que um cliente receba a URL e comece a navegação para ela. No entanto, ele também deve ser longo o suficiente para permitir o desvio do relógio entre servidores. O valor padrão é cinco minutos.

No exemplo a seguir, o valor é estendido para sete minutos:

builder.Services.AddRazorComponents(options => 
    options.TemporaryRedirectionUrlValidityDuration = 
        TimeSpan.FromMinutes(7));

Autenticação Blazor do lado do cliente

Nos aplicativos do cliente de Blazor, as verificações de autenticação no cliente podem ser ignoradas porque todo o código do cliente pode ser modificado pelos utilizadores. O mesmo vale para todas as tecnologias de aplicativos do lado do cliente, incluindo estruturas de SPA JavaScript e aplicativos nativos para qualquer sistema operacional.

Aditar o seguinte:

• Uma referência de pacote para o pacote NuGet Microsoft.AspNetCore.Components.Authorization.

  Observação

  Para obter orientação sobre como adicionar pacotes a aplicações .NET, consulte os artigos em Instalar e gerir pacotes em Fluxo de trabalho de consumo de pacotes (documentação do NuGet). Confirme as versões corretas do pacote em NuGet.org.

• O namespace Microsoft.AspNetCore.Components.Authorization para o ficheiro _Imports.razor do aplicativo.

Para lidar com a autenticação, use o serviço de AuthenticationStateProvider interno ou personalizado.

Para obter mais informações sobre a autenticação do lado do cliente, consulte Secure ASP.NET Core Blazor WebAssembly.

AuthenticationStateProvider serviço

AuthenticationStateProvider é o serviço subjacente usado pelo componente AuthorizeView e serviços de autenticação em cascata para obter o estado de autenticação para um usuário.

Normalmente, você não usa AuthenticationStateProvider diretamente. Use o componente AuthorizeView ou as abordagens Task<AuthenticationState> descritas mais adiante neste artigo. A principal desvantagem de usar AuthenticationStateProvider diretamente é que o componente não é notificado automaticamente se os dados do estado de autenticação subjacente forem alterados.

Para implementar um AuthenticationStateProviderpersonalizado, consulte ASP.NETde estado de autenticação do Core Blazor , que inclui orientações sobre como implementar notificações de alteração de estado de autenticação do usuário.

Obter os dados principais de declarações de um usuário

O serviço AuthenticationStateProvider pode fornecer os dados de ClaimsPrincipal do usuário atual, conforme mostrado no exemplo a seguir.

ClaimsPrincipalData.razor:

@page "/claims-principal-data"
@using System.Security.Claims
@inject AuthenticationStateProvider AuthenticationStateProvider

<h1>ClaimsPrincipal Data</h1>

<button @onclick="GetClaimsPrincipalData">Get ClaimsPrincipal Data</button>

<p>@authMessage</p>

@if (claims.Any())
{
    <ul>
        @foreach (var claim in claims)
        {
            <li>@claim.Type: @claim.Value</li>
        }
    </ul>
}

<p>@surname</p>

@code {
    private string? authMessage;
    private string? surname;
    private IEnumerable<Claim> claims = Enumerable.Empty<Claim>();

    private async Task GetClaimsPrincipalData()
    {
        var authState = await AuthenticationStateProvider
            .GetAuthenticationStateAsync();
        var user = authState.User;

        if (user.Identity is not null && user.Identity.IsAuthenticated)
        {
            authMessage = $"{user.Identity.Name} is authenticated.";
            claims = user.Claims;
            surname = user.FindFirst(c => c.Type == ClaimTypes.Surname)?.Value;
        }
        else
        {
            authMessage = "The user is NOT authenticated.";
        }
    }
}

No exemplo anterior:

• ClaimsPrincipal.Claims retorna as declarações do usuário (claims) para exibição na interface do usuário.
• A linha que obtém o sobrenome do usuário (surname) chama ClaimsPrincipal.FindAll com um predicado para filtrar as declarações do usuário.

Se user.Identity.IsAuthenticated for true e porque o usuário é um ClaimsPrincipal, as declarações podem ser enumeradas e a associação em funções avaliada.

Para obter mais informações sobre injeção de dependência (DI) e serviços, consulte injeção de dependência do ASP.NET Core Blazor e Injeção de dependência no ASP.NET Core. Para obter informações sobre como implementar um AuthenticationStateProviderpersonalizado, consulte ASP.NET Core Blazor estado de autenticação.

Expor o estado de autenticação como um parâmetro em cascata

Se os dados do estado de autenticação forem necessários para a lógica processual, como ao executar uma ação acionada pelo usuário, obtenha os dados do estado de autenticação definindo um parâmetro em cascata do tipo Task<AuthenticationState>, como demonstra o exemplo a seguir.

CascadeAuthState.razor:

@page "/cascade-auth-state"

<h1>Cascade Auth State</h1>

<p>@authMessage</p>

@code {
    private string authMessage = "The user is NOT authenticated.";

    [CascadingParameter]
    private Task<AuthenticationState>? authenticationState { get; set; }

    protected override async Task OnInitializedAsync()
    {
        if (authenticationState is not null)
        {
            var authState = await authenticationState;
            var user = authState?.User;

            if (user?.Identity is not null && user.Identity.IsAuthenticated)
            {
                authMessage = $"{user.Identity.Name} is authenticated.";
            }
        }
    }
}

Se user.Identity.IsAuthenticated for true, as afirmações podem ser enumeradas e a participação em funções ser avaliada.

Configure o parâmetro em cascata Task<AuthenticationState> usando os serviços de autenticação em cascata e de estado AuthorizeRouteView.

Quando você cria um aplicativo Blazor a partir de um dos modelos de projeto Blazor com a autenticação habilitada, o aplicativo inclui o AuthorizeRouteView e a chamada para AddCascadingAuthenticationState mostrados no exemplo a seguir. Uma aplicação Blazor no lado cliente também inclui os registos de serviço necessários. Informações adicionais são apresentadas na seção Personalizar o conteúdo não autorizado com o componente Router.

<Router ...>
    <Found ...>
        <AuthorizeRouteView RouteData="routeData" 
            DefaultLayout="typeof(Layout.MainLayout)" />
        ...
    </Found>
</Router>

No arquivo Program, registre os serviços de estado de autenticação em cascata:

builder.Services.AddCascadingAuthenticationState();

Num aplicativo cliente Blazor, adicione serviços de autorização ao ficheiro Program:

builder.Services.AddAuthorizationCore();

Em um aplicativo de Blazor do lado do servidor, os serviços de opções e autorização já estão presentes, portanto, nenhuma etapa adicional é necessária.

Autorização

Depois que um utilizador é autenticado, regras de autorização são aplicadas para controlar o que o utilizador pode fazer.

Normalmente, o acesso é concedido ou negado com base no seguinte:

• Um usuário é autenticado (conectado).
• Um utilizador está numa função .
• Um utilizador tem uma reivindicação .
• Uma política é satisfeita.

Cada um desses conceitos é o mesmo que em um aplicativo ASP.NET Core MVC ou Razor Pages. Para obter mais informações sobre a segurança ASP.NET Core, consulte os artigos em ASP.NET Core Security and Identity.

componente AuthorizeView

O componente AuthorizeView exibe seletivamente o conteúdo da interface do usuário, dependendo se o usuário está autorizado. Essa abordagem é útil quando você só precisa exibir dados de para o usuário e não precisa usar o identity do usuário na lógica processual.

O componente expõe uma variável context do tipo AuthenticationState (@context na sintaxe Razor), que você pode usar para acessar informações sobre o usuário conectado:

<AuthorizeView>
    <p>Hello, @context.User.Identity?.Name!</p>
</AuthorizeView>

Você também pode fornecer conteúdo diferente para exibição se o usuário não estiver autorizado com uma combinação dos parâmetros Authorized e NotAuthorized:

<AuthorizeView>
    <Authorized>
        <p>Hello, @context.User.Identity?.Name!</p>
        <p><button @onclick="HandleClick">Authorized Only Button</button></p>
    </Authorized>
    <NotAuthorized>
        <p>You're not authorized.</p>
    </NotAuthorized>
</AuthorizeView>

@code {
    private void HandleClick() { ... }
}

Embora o componente AuthorizeView controle a visibilidade dos elementos com base no status de autorização do usuário, ele não impõe segurança no próprio manipulador de eventos. No exemplo anterior, o método HandleClick é associado apenas a um botão visível para usuários autorizados, mas nada impede que esse método seja invocado de outros lugares. Para garantir a segurança no nível do método, implemente uma lógica de autorização adicional no próprio manipulador ou na API relevante.

Razor componentes do Blazor Web Appnunca exibem conteúdo <NotAuthorized> quando a autorização falha durante a renderização estática no servidor (SSR estático). O pipeline do ASP.NET Core do lado do servidor processa a autorização no servidor. Use técnicas do lado do servidor para lidar com solicitações não autorizadas. Para obter mais informações, consulte modos de renderização do ASP.NET Core Blazor.

Advertência

Os elementos de marcação e os métodos do lado do cliente associados a um AuthorizeView só são protegidos contra exibição e execução na interface do usuário renderizada em aplicativos do lado do cliente Blazor. Para proteger o conteúdo autorizado e métodos seguros no Blazordo lado do cliente, o conteúdo geralmente é fornecido por uma chamada de API da Web segura e autorizada para uma API de servidor e nunca é armazenado no aplicativo. Para obter mais informações, consulte chamar uma API da Web de um aplicativo ASP.NET Core Blazor e ASP.NET Core Blazor WebAssembly cenários de segurança adicionais.

O conteúdo de Authorized e NotAuthorized pode incluir itens arbitrários, como outros componentes interativos.

As condições de autorização, como funções ou políticas que controlam as opções ou o acesso da interface do usuário, são abordadas na seção de autorização.

Se as condições de autorização não forem especificadas, AuthorizeView usará uma política padrão:

• Os usuários autenticados (conectados) são autorizados.
• Os usuários não autenticados (desconectados) não são autorizados.

O componente AuthorizeView pode ser usado no componente NavMenu (Shared/NavMenu.razor) para exibir um componente NavLink (NavLink), mas observe que essa abordagem apenas remove o item de lista da saída renderizada. Isso não impede que o usuário navegue até o componente. Implemente a autorização separadamente no componente de destino.

Autorização baseada em funções e políticas

O componente oferece suporte a autorização baseada em função ou autorização baseada em política .

Para autorização baseada em função, use o parâmetro Roles. No exemplo a seguir, o usuário deve ter uma declaração de função para as funções Admin ou Superuser:

<AuthorizeView Roles="Admin, Superuser">
    <p>You have an 'Admin' or 'Superuser' role claim.</p>
</AuthorizeView>

Para exigir que um utilizador tenha declarações de função Admin e Superuser, aninhe os componentes AuthorizeView:

<AuthorizeView Roles="Admin">
    <p>User: @context.User</p>
    <p>You have the 'Admin' role claim.</p>
    <AuthorizeView Roles="Superuser" Context="innerContext">
        <p>User: @innerContext.User</p>
        <p>You have both 'Admin' and 'Superuser' role claims.</p>
    </AuthorizeView>
</AuthorizeView>

O código anterior define um Context para o componente interno AuthorizeView, de forma a evitar uma colisão no contexto AuthenticationState. O contexto AuthenticationState é acedido na AuthorizeView externa com o método padrão para aceder ao contexto (@context.User). O contexto na AuthorizeView interna é acessado com o contexto nomeado innerContext (@innerContext.User).

Para obter mais informações, incluindo diretrizes de configuração, consulte Autorização baseada em função no ASP.NET Core.

Para autorização baseada em política, use o parâmetro Policy com um único nome de política:

<AuthorizeView Policy="Over21">
    <p>You satisfy the 'Over21' policy.</p>
</AuthorizeView>

Para lidar com o caso em que o usuário deve satisfazer uma das várias políticas, crie uma política que confirme que o usuário satisfaz outras políticas.

Para lidar com o caso em que o usuário deve satisfazer várias políticas simultaneamente, execute uma das seguintes abordagens:

• Crie uma política para AuthorizeView que confirme que o usuário satisfaz várias outras políticas.

• Incorporar as políticas em vários componentes AuthorizeView:

  <AuthorizeView Policy="Over21">
      <AuthorizeView Policy="LivesInCalifornia">
          <p>You satisfy the 'Over21' and 'LivesInCalifornia' policies.</p>
      </AuthorizeView>
  </AuthorizeView>
  

A autorização baseada em declarações é um caso especial de autorização baseada em políticas. Por exemplo, você pode definir uma política que exija que os usuários tenham uma determinada declaração. Para obter mais informações, consulte autorização baseada em políticas no ASP.NET Core.

Se nem Roles nem Policy for especificado, AuthorizeView usará a política padrão:

• Os usuários autenticados (conectados) são autorizados.
• Os usuários não autenticados (desconectados) não são autorizados.

Como as strings .NET são sensíveis a maiúsculas e minúsculas, a correspondência de nomes de função e política também é sensível a maiúsculas e minúsculas. Por exemplo, Admin (em maiúsculas A) não é considerado o mesmo papel que admin (em minúsculas a).

O caso Pascal é normalmente usado para nomes de funções e políticas (por exemplo, BillingAdministrator), mas o uso do caso Pascal não é um requisito estrito. Diferentes esquemas de invólucro, como caixa de camelo, caixa de kebab e caixa de cobra, são permitidos. O uso de espaços em nomes de funções e políticas é incomum, mas permitido pela estrutura. Por exemplo, billing administrator é um formato de nome de política ou função incomum em aplicativos .NET, mas é um nome de função ou política válido.

Conteúdo exibido durante a autenticação assíncrona

Blazor permite que o estado de autenticação seja determinado de forma assíncrona. O cenário principal para esta abordagem é em aplicações de Blazor do lado do cliente que fazem uma solicitação a um ponto de extremidade externo para autenticação.

Enquanto a autenticação está em andamento, AuthorizeView não exibe conteúdo. Para exibir conteúdo enquanto a autenticação ocorre, atribua o conteúdo ao parâmetro Authorizing:

<AuthorizeView>
    <Authorized>
        <p>Hello, @context.User.Identity?.Name!</p>
    </Authorized>
    <Authorizing>
        <p>You can only see this content while authentication is in progress.</p>
    </Authorizing>
</AuthorizeView>

Essa abordagem normalmente não é aplicável a aplicativos de Blazor do lado do servidor. Os aplicativos Blazor do lado do servidor conhecem o estado de autenticação assim que o estado é estabelecido. O conteúdo Authorizing pode ser fornecido no componente AuthorizeView de um aplicativo, mas nunca é exibido.

[Authorize] atributo

O atributo [Authorize] está disponível nos componentes Razor.

@page "/"
@attribute [Authorize]

You can only see this if you're signed in.

Importante

Utilize apenas [Authorize] em componentes @page alcançados através do roteador Blazor. A autorização é executada apenas como um aspeto do roteamento e não para componentes-filho renderizados numa página. Para autorizar a exibição de partes específicas dentro de uma página, use AuthorizeView em vez disso.

O atributo [Authorize] também oferece suporte à autorização baseada em função ou política. Para autorização baseada em função, use o parâmetro Roles:

@page "/"
@attribute [Authorize(Roles = "Admin, Superuser")]

<p>You can only see this if you're in the 'Admin' or 'Superuser' role.</p>

Para autorização baseada em política, use o parâmetro Policy:

@page "/"
@attribute [Authorize(Policy = "Over21")]

<p>You can only see this if you satisfy the 'Over21' policy.</p>

Se nem Roles nem Policy for especificado, [Authorize] usará a política padrão:

• Os usuários autenticados (conectados) são autorizados.
• Os usuários não autenticados (desconectados) não são autorizados.

Quando o usuário não está autorizado e se o aplicativo não personalizar conteúdo não autorizado com o componente Router, a estrutura exibe automaticamente a seguinte mensagem de fallback:

Not authorized.

Autorização de recursos

Para autorizar usuários para recursos, passe os dados de rota da solicitação para o parâmetro Resource de AuthorizeRouteView.

No conteúdo do Router.Found para uma rota solicitada:

<AuthorizeRouteView Resource="routeData" RouteData="routeData" 
    DefaultLayout="typeof(MainLayout)" />

Para obter mais informações sobre como os dados de estado de autorização são passados e usados na lógica de procedimento, consulte a seção Expor o estado de autenticação como um parâmetro em cascata.

Quando o AuthorizeRouteView recebe os dados de rota para o recurso, as políticas de autorização têm acesso a RouteData.PageType e RouteData.RouteValues que permitem que a lógica personalizada tome decisões de autorização.

No exemplo a seguir, uma política de EditUser é criada em AuthorizationOptions para a configuração do serviço de autorização do aplicativo (AddAuthorizationCore) com a seguinte lógica:

• Determine se existe um valor de rota com uma chave de id. Se a chave existir, o valor da rota será armazenado em value.
• Em uma variável chamada id, armazenevalue como uma cadeia de caracteres ou defina um valor de cadeia de caracteres vazio (string.Empty).
• Se id não for uma cadeia de caracteres vazia, afirme que a política está satisfeita (retornar true) se o valor da cadeia começar com EMP. Caso contrário, afirme que a política falha (retornar false).

No ficheiro Program:

• Adicione namespaces para Microsoft.AspNetCore.Components e System.Linq:

  using Microsoft.AspNetCore.Components;
  using System.Linq;
  

• Adicione a política:

  options.AddPolicy("EditUser", policy =>
      policy.RequireAssertion(context =>
      {
          if (context.Resource is RouteData rd)
          {
              var routeValue = rd.RouteValues.TryGetValue("id", out var value);
              var id = Convert.ToString(value, 
                  System.Globalization.CultureInfo.InvariantCulture) ?? string.Empty;
  
              if (!string.IsNullOrEmpty(id))
              {
                  return id.StartsWith("EMP", StringComparison.InvariantCulture);
              }
          }
  
          return false;
      })
  );
  

O exemplo anterior é uma política de autorização excessivamente simplificada, usada apenas para demonstrar o conceito com um exemplo de trabalho. Para obter mais informações sobre como criar e configurar políticas de autorização, consulte autorização baseada em políticas no ASP.NET Core.

No componente EditUser seguinte, o recurso em /users/{id}/edit tem um parâmetro de rota para o identificador do utilizador ({id}). O componente utiliza a anterior política de autorização de EditUser para ver se o valor de rota para id começa com EMP. Se id começar com EMP, a política será bem-sucedida e o acesso ao componente será autorizado. Se id começar com um valor diferente de EMP ou se id for uma cadeia de caracteres vazia, a política falhará e o componente não será carregado.

EditUser.razor:

@page "/users/{id}/edit"
@using Microsoft.AspNetCore.Authorization
@attribute [Authorize(Policy = "EditUser")]

<h1>Edit User</h1>

<p>The "EditUser" policy is satisfied! <code>Id</code> starts with 'EMP'.</p>

@code {
    [Parameter]
    public string? Id { get; set; }
}

Personalizar conteúdo não autorizado com o componente Router

O componente Router, em conjunto com o componente AuthorizeRouteView, permite que o aplicativo especifique conteúdo personalizado se:

• O usuário falha uma condição de [Authorize] aplicada ao componente. A marcação do elemento <NotAuthorized> é exibida. O atributo [Authorize] é abordado na seção atributo [Authorize].
• A autorização assíncrona está em andamento, o que geralmente significa que o processo de autenticação do usuário está em andamento. A marcação do elemento <Authorizing> é exibida.

Importante

Os recursos do roteador Blazor que exibem conteúdo <NotAuthorized> e <NotFound> não estão a funcionar durante a renderização estática do lado do servidor (SSR estático) porque o processamento de solicitações é totalmente gerido pelo pipeline de middleware do ASP.NET Core, e os componentes Razor não são renderizados para solicitações não autorizadas ou incorretas. Use técnicas do lado do servidor para lidar com solicitações não autorizadas e incorretas durante o SSR estático. Para obter mais informações, consulte os modos de renderização do ASP.NET Core Blazor.

<Router ...>
    <Found ...>
        <AuthorizeRouteView ...>
            <NotAuthorized>
                ...
            </NotAuthorized>
            <Authorizing>
                ...
            </Authorizing>
        </AuthorizeRouteView>
    </Found>
</Router>

O conteúdo de Authorized e NotAuthorized pode incluir itens arbitrários, como outros componentes interativos.

Observação

O anterior requer o registro de serviços de estado de autenticação em cascata no arquivo Program do aplicativo:

builder.Services.AddCascadingAuthenticationState();

Se o conteúdo NotAuthorized não for especificado, o AuthorizeRouteView usará a seguinte mensagem de substituição:

Not authorized.

Um aplicativo criado a partir do modelo de projeto Blazor WebAssembly com autenticação habilitada inclui um componente RedirectToLogin, que é posicionado no conteúdo <NotAuthorized> do componente Router. Quando um usuário não é autenticado (context.User.Identity?.IsAuthenticated != true), o componente RedirectToLogin redireciona o navegador para o ponto de extremidade authentication/login para autenticação. O usuário é retornado à URL solicitada após a autenticação com o provedor de identity.

Lógica processual

Se for necessário que o aplicativo verifique as regras de autorização como parte da lógica processual, use um parâmetro em cascata do tipo Task<AuthenticationState> para obter a ClaimsPrincipaldo usuário. Task< AuthenticationState > pode ser combinado com outros serviços, como IAuthorizationService, para avaliar políticas.

No exemplo a seguir:

• O user.Identity.IsAuthenticated executa código para usuários autenticados (conectados).
• O user.IsInRole("admin") executa código para usuários na função 'Admin'.
• O (await AuthorizationService.AuthorizeAsync(user, "content-editor")).Succeeded executa código para usuários que satisfazem a política de 'editor de conteúdo'.

Um aplicativo Blazor do lado do servidor inclui os namespaces apropriados quando criado a partir do modelo de projeto. Em um aplicativo de Blazor do lado do cliente, confirme a presença dos namespaces Microsoft.AspNetCore.Authorization e Microsoft.AspNetCore.Components.Authorization no componente ou no arquivo _Imports.razor do aplicativo:

@using Microsoft.AspNetCore.Authorization
@using Microsoft.AspNetCore.Components.Authorization

ProceduralLogic.razor:

@page "/procedural-logic"
@inject IAuthorizationService AuthorizationService

<h1>Procedural Logic Example</h1>

<button @onclick="@DoSomething">Do something important</button>

@code {
    [CascadingParameter]
    private Task<AuthenticationState>? authenticationState { get; set; }

    private async Task DoSomething()
    {
        if (authenticationState is not null)
        {
            var authState = await authenticationState;
            var user = authState?.User;

            if (user is not null)
            {
                if (user.Identity is not null && user.Identity.IsAuthenticated)
                {
                    // ...
                }

                if (user.IsInRole("Admin"))
                {
                    // ...
                }

                if ((await AuthorizationService.AuthorizeAsync(user, "content-editor"))
                    .Succeeded)
                {
                    // ...
                }
            }
        }
    }
}

Solucionar erros

Erros comuns:

• A autorização requer um parâmetro em cascata do tipo Task<AuthenticationState>. Considere usar CascadingAuthenticationState para fornecer isso.

• null valor é recebido para authenticationStateTask

É provável que o projeto não tenha sido criado usando um modelo de Blazor do lado do servidor com autenticação habilitada.

No .NET 7 ou anterior, envolva uma <CascadingAuthenticationState> em torno de alguma parte da árvore da interface do usuário, por exemplo, em torno do roteador Blazor:

<CascadingAuthenticationState>
    <Router ...>
        ...
    </Router>
</CascadingAuthenticationState>

No .NET 8 ou posterior, não use o componente CascadingAuthenticationState:

- <CascadingAuthenticationState>
      <Router ...>
          ...
      </Router>
- </CascadingAuthenticationState>

Em vez disso, adicione serviços de estado de autenticação em cascata à coleção de serviços no arquivo Program:

builder.Services.AddCascadingAuthenticationState();

Os serviços fornecidos pelo componente CascadingAuthenticationState (.NET 7 ou anterior) ou pelo AddCascadingAuthenticationState (.NET 8 ou posterior) fornecem o parâmetro em cascata Task<AuthenticationState>, que, por sua vez, recebe do serviço subjacente de injeção de dependência AuthenticationStateProvider.

Informações de identificação pessoal (PII)

A Microsoft usa a definição GDPR para "dados pessoais" (GDPR 4.1) quando a documentação discute Informações de Identificação Pessoal (PII).

PII refere-se a qualquer informação relativa a uma pessoa singular identificada ou identificável. Uma pessoa singular identificável é aquela que possa ser identificada, direta ou indiretamente, com qualquer um dos seguintes elementos:

• Nome
• Número de identificação
• Coordenadas de localização
• Identificador em linha
• Outros fatores específicos
  • Física
  • Fisiológico
  • Genética
  • Mental (psicológico)
  • Aspetos económicos
  • Culturais
  • identity Social

Recursos adicionais

• Recursos do lado do servidor e do Blazor Web App
  • Guia de início rápido: adicionar início de sessão com a Microsoft a uma aplicação Web ASP.NET Core
  • Guia de início rápido: proteja uma API da Web ASP.NET Core com a plataforma Microsoft identity
  • Configurar ASP.NET Core para trabalhar com servidores proxy e balanceadores de carga: Inclui orientações sobre:
    • Usando middleware de cabeçalhos encaminhados para preservar as informações do esquema HTTPS em servidores proxy e redes internas.
    • Cenários e casos de uso adicionais, incluindo configuração manual do esquema, alterações de caminho de pedido para o roteamento correto das solicitações e o encaminhamento do esquema de pedido para proxies reversos em Linux e não-IIS.
• Documentação da plataforma Microsoft identity
  • Visão geral
  • protocolos OAuth 2.0 e OpenID Connect na plataforma Microsoft identity
  • Plataforma Microsoft identity e fluxo de código de autorização OAuth 2.0
  • de tokens de ID de plataforma do Microsoft identity
  • Tokens de acesso à plataforma Microsoft identity
• ASP.NET Principais tópicos de segurança
• Configurar a Autenticação do Windows no ASP.NET Core
• Crie uma versão personalizada da biblioteca JavaScript Authentication.MSAL
• Awesome Blazor: Autenticação exemplos de links da comunidade
• ASP.NET Core Blazor Hybrid autenticação e autorização