Autenticação e autorização do Blazor no ASP.NET Core
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, consulte a Política de Suporte do .NET e do .NET Core. Para a versão atual, consulte a versão .NET 9 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.
Este artigo descreve o suporte do ASP.NET Core para a configuração e o gerenciamento de segurança em aplicativos Blazor.
O Blazor usa os mecanismos de autenticação do ASP.NET Core para estabelecer a identity do usuário. O mecanismo exato depende de como o aplicativo Blazor está hospedado, no 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 são capazes de impor regras de acesso para áreas do aplicativo e componentes. Como a execução do código do lado do cliente pode ser adulterada, não se pode confiar no código de autorização em execução no cliente para impor regras de acesso ou controlar a exibição do conteúdo do lado do cliente.
Se a aplicação da regra de autorização tiver de ser garantida, não implemente verificações de autorização no código do lado do cliente. Crie um Blazor Web App que dependa apenas da SSR (renderização do lado do servidor) para verificações de autorização e aplicação de regras.
Se a aplicação das regras de autorização e a segurança dos dados e do código precisarem ser garantidas, não desenvolva um aplicativo do lado do cliente. Crie um aplicativo Blazor Server.
As convenções de autorização do Razor Pages não se aplicam a componentes Razor roteáveis. Se um componente Razor não roteável for inserido em uma página de um aplicativo do Razor Pages, as convenções de autorização da página afetarão indiretamente o componente Razor junto com o rest do conteúdo da página.
O ASP.NET Core Identity foi projetado para funcionar no contexto da comunicação de solicitação e resposta HTTP, que geralmente não é o modelo de comunicação cliente-servidor do aplicativo Blazor. Os aplicativos ASP.NET Core que usam o ASP.NET Core Identity para gerenciamento de usuários devem usar Razor Pages em vez de componentes Razor para interface do usuário relacionada a Identity, como registro de usuário, logon, logoff e outras tarefas de gerenciamento de usuários. A criação de componentes Razor que lidam diretamente com tarefas Identity é possível para vários cenários, mas não é recomendada ou compatível com a Microsoft.
Abstrações do ASP.NET Core, como SignInManager<TUser> eUserManager<TUser>, não têm suporte em componentes Razor. Para obter mais informações sobre como usar o ASP.NET Core Identity com Blazor, confira Scaffold ASP.NET CoreIdentity em um aplicativo Blazor do lado do servidor.
Observação
Os exemplos de código neste artigo adotam NRTs (tipos de referência anuláveis) e análise estática de estado nulo do compilador do .NET, que têm suporte no ASP.NET Core no .NET 6 ou posterior. Ao usar o ASP.NET Core 5.0 ou anterior, remova a designação de tipo nulo (?
) dos exemplos neste artigo.
Mantenha dados e credenciais confidenciais com segurança
Não armazene segredos de aplicativo, cadeias de conexão, credenciais, senhas, PINs (números de identificação pessoal), código .NET/C# privado ou chaves/tokens privados no código do lado do cliente, que é sempre inseguro. O código do lado Blazor do cliente deve acessar serviços e bancos de dados seguros por meio de uma API Web segura que você controla.
Em ambientes de teste/preparo e produção, o código do lado do Blazor servidor e as APIs Web devem usar fluxos de autenticação seguros que evitam 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 Gerenciador de segredos é recomendada para proteger dados confidenciais. Para saber mais, consulte os recursos a seguir:
- Fluxos de autenticação seguros (documentação principal do ASP.NET)
- Identidades gerenciadas para serviços do Microsoft Azure (este artigo)
Para desenvolvimento e teste local do lado do cliente e do lado 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 autenticam de maneira segura para serviços do Azure sem armazenar credenciais no código do aplicativo. Para saber mais, consulte os recursos a seguir:
- O que são identidades gerenciadas para recursos do Azure? (Documentação do Microsoft Entra)
- Documentação dos serviços do Azure
Suporte à anti-falsificação
O modelo Blazor:
- Adiciona serviços antifalsificação automaticamente quando AddRazorComponents é chamado no arquivo
Program
. - Adiciona middleware antifalsificação chamando UseAntiforgery em seu pipeline de processamento de solicitação no arquivo
Program
e requer proteção antifalsificação do ponto de extremidade para mitigar as ameaças de CSRF/XSRF (solicitação intersite forjada). 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 (EditForm) do formulário. Para obter mais informações, consulte ASP.NET CoreBlazor Visão geral dos formulários.
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 AntiforgeryRequestToken atual. Para obter mais informações, consulte Chame uma API Web de um Blazoraplicativo ASP.NET Core.
Blazor armazena tokens de solicitação no estado do componente, o que garante que os tokens antifalsificação estejam disponíveis para os componentes interativos, mesmo quando eles não têm acesso à solicitação.
Observação
A 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-data
ou text/plain
, pois esses são os únicos tipos de formulário válidos.
Para saber mais, consulte os recursos a seguir:
- Prevenir ataques de XSRF/CSRF (solicitação intersite forjada) no ASP.NET Core: esse artigo é o principal artigo do ASP.NET Core sobre o assunto, que se aplica ao Blazor Server do lado do servidor, ao projeto de servidor dos Blazor Web Apps e à integração do Blazor às Páginas MVC/Razor.
- Blazor Visão geral de formulários do ASP.NET Core: A seção suporte antifalsificação do artigo refere-se ao Blazor 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 forma 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 uma SignalR conexão com o cliente. A autenticação pode ser baseada em um cookie ou em outro token de portador, mas a autenticação é gerenciada por meio do hub SignalR e totalmente 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 o aplicativo precisar capturar usuários para serviços personalizados ou reagir a atualizações para o usuário, consulte ASP.NET Cenários de segurança adicionais e Blazor Web App do lado do servidor Core.
Blazor difere de aplicativos Web tradicionais renderizados pelo servidor que fazem novas solicitações HTTP com cookies em cada navegação de página. A autenticação é verificada durante eventos de navegação. No entanto, cookies não estão envolvidos. Cookies são enviados somente ao fazer uma solicitação HTTP a um servidor, o que não ocorre quando o usuário navega em um aplicativo do Blazor. Durante a navegação, o estado de autenticação do usuário é verificado dentro do circuito Blazor, que você pode atualizar a qualquer momento no servidor usando a abstração RevalidatingAuthenticationStateProvider
.
Importante
Não é recomendável implementar um NavigationManager
personalizado para obter validação de autenticação durante a navegação. Se o aplicativo precisar executar a lógica de estado de autenticação personalizada durante a navegação, use um personalizado AuthenticationStateProvider
.
Observação
Os exemplos de código neste artigo adotam NRTs (tipos de referência anuláveis) e análise estática de estado nulo do compilador do .NET, que têm suporte no ASP.NET Core no .NET 6 ou posterior. Ao usar o ASP.NET Core 5.0 ou anterior, remova a designação de tipo nulo (?
) dos exemplos deste artigo.
O serviço AuthenticationStateProvider interno ou personalizado obtém dados de estado de autenticação do HttpContext.User do ASP.NET Core. Essa é a maneira que o estado de autenticação se integra a mecanismos de autenticação existentes do ASP.NET Core.
Para obter mais informações sobre autenticação do lado do servidor, consulte Blazor do núcleo.
IHttpContextAccessor
/HttpContext
em Razor componentes
IHttpContextAccessor deve ser evitado com a renderização interativa porque não há um HttpContext
disponível válido.
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 apenas 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 componente HttpContext é necessário em componentes interativos, recomendamos fluir os dados por meio do estado de componente persistente do servidor. Para obter mais informações, consulte Blazor Web App de segurança adicionais e do lado do servidor Core.
Não use IHttpContextAccessor/HttpContext direta ou indiretamente nos componentes Razor dos aplicativos Blazor do lado do servidor. Os aplicativos Blazor são executados fora do contexto do pipeline ASP.NET Core. Não há garantia de que o HttpContext esteja disponível no IHttpContextAccessor e não há garantia de que o HttpContext mantenha o contexto que iniciou o aplicativo Blazor.
A abordagem recomendada para passar o estado da solicitação para o aplicativo Blazor é por meio de parâmetros de componente raiz durante a renderização inicial do aplicativo. Como alternativa, o aplicativo pode copiar os dados para um serviço com escopo no evento de ciclo de vida de inicialização do componente raiz para uso em todo o aplicativo. Para obter mais informações, consulte Blazor Web App de segurança adicionais e do lado do servidor Core.
Um aspecto crítico da segurança do lado do servidor Blazor é que o usuário anexado a um determinado circuito pode ser atualizado em algum momento após o circuito Blazor ser estabelecido, mas o IHttpContextAccessornão é atualizado. Para obter mais informações sobre como lidar com essa situação com serviços personalizados, consulte Blazor Web App de segurança adicionais e do lado do servidor Core.
Estado compartilhado
Os aplicativos Blazor do lado do servidor estão localizados na memória do servidor, e várias sessões de aplicativo são hospedadas no mesmo processo. Para cada sessão de aplicativo, Blazor inicia um circuito com seu próprio escopo de contêiner de injeção de dependência. Portanto, os serviços com escopo são exclusivos por sessão Blazor.
Aviso
Não recomendamos que os aplicativos no mesmo estado de compartilhamento de servidor usem serviços singleton, a menos que sejam tomados cuidados extremos, pois isso pode introduzir vulnerabilidades de segurança, como o vazamento do estado do usuário entre circuitos.
Você pode usar serviços singleton com estado em aplicativos Blazor, se forem criados 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 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 vazará entre circuitos.
Para obter diretrizes gerais sobre o gerenciamento de estado, confira Gerenciamento de estado Blazor do ASP.NET Core.
Segurança do lado do servidor de dados e credenciais confidenciais
Em ambientes de teste/preparo e produção, o código do lado do Blazor servidor e as APIs Web devem usar fluxos de autenticação seguros que evitam 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 Gerenciador de segredos é recomendada para proteger dados confidenciais. Para saber mais, consulte os recursos a seguir:
- Fluxos de autenticação seguros (documentação principal do ASP.NET)
- Identidades gerenciadas para serviços do Microsoft Azure (Blazor documentação)
Para desenvolvimento e teste local do lado do cliente e do lado 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 diretrizes em Ferramentas para Blazor do ASP.NET Core.
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): nenhuma autenticação.
- Contas individuais: as contas de usuário são armazenadas no aplicativo usando ASP.NET Core Identity.
- Nenhum (padrão): nenhuma autenticação.
- Contas individuais: as contas de usuário são armazenadas no aplicativo usando ASP.NET Core Identity.
- Plataforma de identity da Microsoft: para mais informações, consulte Autenticação e autorização do ASP.NET Core Blazor.
- Windows: use a Autenticação do Windows.
Interface do usuário BlazorIdentity (contas individuais)
Blazor dá suporte à geração de uma interface do usuário Blazor completa baseada em Identity quando você escolhe a opção de autenticação para Contas Individuais.
O modelo do Blazor Web App faz o scaffold de código do Identity em um banco de dados do SQL Server. A versão da linha de comando usa SQLite e inclui um banco de dados SQLite para Identity.
O modelo :
- é compatível com cenários de SSR interativa (renderização do lado do servidor interativa) 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 conectar e desconectar usuários. Os componentes Identity também são compatíveis com recursos avançados de Identity, como confirmação de conta e recuperação de senha e autenticação multifator usando um aplicativo de terceiros. Os componentes Identity em si não suportam interatividade.
- Adiciona os pacotes e dependências relacionados a 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 os pontos de extremidade Identity internos.
- Inclui validação de Identity e lógica de negócios.
Para inspecionar os componentes Blazor da estrutura Identity, acesse-os nas pastas Pages
e Shared
da pasta da Account
no modelo de projeto do Blazor Web App (fonte de referência).
Quando você escolhe os modos de renderização interativa WebAssembly ou renderização automática, o servidor lida com todas as solicitações de autenticação e autorização, e os componentes Identity são renderizados estaticamente no servidor no projeto principal do Blazor Web App.
A estrutura fornece um AuthenticationStateProvider personalizado nos projetos do servidor e do cliente (.Client
) para o fluxo do estado de autenticação do usuário para o navegador. O projeto do servidor chama AddAuthenticationStateSerialization
, enquanto o projeto do cliente chama AddAuthenticationStateDeserialization
. A autenticação no servidor em vez de no cliente permite que o aplicativo acesse o estado de autenticação durante a pré-renderização e antes que o runtime do .NET WebAssembly seja inicializado. As implementações AuthenticationStateProvider personalizadas usam o serviço Estado de Componente Persistente (PersistentComponentState) para serializar o estado de autenticação em comentários HTML e, em seguida, lê-lo de volta do WebAssembly para criar uma instância AuthenticationState. Para mais informações, consulte a seção Gerenciar o estado da autenticação em Blazor Web Apps.
Somente para soluções de Servidor Interativo, IdentityRevalidatingAuthenticationStateProvider
(fonte de referência) é um AuthenticationStateProvider lado do servidor que revalida o carimbo de segurança do usuário conectado a cada 30 minutos em que um circuito interativo está conectado.
Quando você escolhe os modos de renderização interativa WebAssembly ou renderização automática, o servidor lida com todas as solicitações de autenticação e autorização, e os componentes Identity são renderizados estaticamente no servidor no projeto principal do Blazor Web App. O modelo de projeto inclui uma classe PersistentAuthenticationStateProvider
(fonte de referência) no projeto .Client
para sincronizar o estado de autenticação do usuário entre o servidor e o navegador. A classe é uma implementação personalizada de AuthenticationStateProvider. O provedor usa o serviço Estado Persistente do Componente (PersistentComponentState) para pré-renderizar o estado de autenticação e mantê-lo na página.
No projeto principal de um Blazor Web App, o provedor de estado de autenticação se chama IdentityRevalidatingAuthenticationStateProvider
(fonte de referência) (somente as soluções de interatividade do servidor) ou PersistingRevalidatingAuthenticationStateProvider
(fonte de referência) (soluções de interatividade WebAssembly ou Automática).
BlazorIdentity depende de instâncias DbContext não criadas por uma fábrica, o que é intencional porque DbContext é suficiente para que os componentes Identity do modelo de projeto sejam renderizados estaticamente sem dar 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 ASP.NET Core Blazor Modos de renderização.
Para obter mais informações sobre como persistir o estado pré-renderizado, confira Pré-renderizar componentes do ASP.NET Core Razor.
Observação
Os links de documentação para a fonte de referência do .NET geralmente carregam o branch padrão do repositório, que representa o desenvolvimento atual da próxima versão do .NET. Para selecionar uma marca para uma versão específica, use a lista suspensa para Alternar branches ou marcas. Para saber mais, confira 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 em Blazor Web Apps
Esta seção se aplica a Blazor Web Apps que adotam:
- Contas Individuais
- Renderização no lado do cliente (CSR, interatividade baseada em WebAssembly).
Um provedor de estado de autenticação do lado do cliente é usado somente em Blazor e não está integrado ao sistema de autenticação do 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, é usado um provedor de autenticação no lado do cliente. Quando o usuário atualiza a página (recarrega a 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 é mantido pelo servidor, qualquer estado de autenticação mantido no lado do cliente é perdido.
Para resolver isso, a melhor abordagem é realizar a autenticação no sistema de autenticação do ASP.NET Core. O provedor de estado de autenticação no lado do cliente só se encarrega 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 do Blazor Web App e descritos abaixo.
No arquivo Program
do projeto do servidor, chame AddAuthenticationStateSerialization
, que serializa o AuthenticationState retornado pelo AuthenticationStateProvider do lado do servidor usando o serviço Estado Persistente do Componente (PersistentComponentState):
builder.Services.AddRazorComponents()
.AddInteractiveWebAssemblyComponents()
.AddAuthenticationStateSerialization();
A API só serializa as declarações de nome e função do lado do servidor para acesso no navegador. Para incluir todas as declarações, defina SerializeAllClaims
para true
na chamada do lado do servidor para AddAuthenticationStateSerialization
:
builder.Services.AddRazorComponents()
.AddInteractiveWebAssemblyComponents()
.AddAuthenticationStateSerialization(
options => options.SerializeAllClaims = true);
No arquivo .Client
do projeto do cliente (Program
), chame AddAuthenticationStateDeserialization
, que adiciona um AuthenticationStateProvider em que o AuthenticationState é desserializado do servidor usando AuthenticationStateData
e o serviço Estado Persistente do Componente (PersistentComponentState). Deve haver uma chamada correspondente para AddAuthenticationStateSerialization
no projeto do servidor.
builder.Services.AddAuthorizationCore();
builder.Services.AddCascadingAuthenticationState();
builder.Services.AddAuthenticationStateDeserialization();
PersistingRevalidatingAuthenticationStateProvider
(fonte de referência): para Blazor Web Apps que adotam a SSR interativa (renderização interativa do lado do servidor) e a CSR (renderização do lado do cliente). Este é um AuthenticationStateProvider do lado do servidor que revalida o selo de segurança para o usuário conectado a cada 30 minutos em que um circuito interativo está conectado. Ele também usa o serviço Estado do Componente Persistente para transmitir o estado de autenticação ao cliente, que é então fixado para o tempo de vida da CSR.PersistingServerAuthenticationStateProvider
(fonte de referência): para Blazor Web Apps que adotam apenas a CSR. Esse é um AuthenticationStateProvider do lado do servidor que usa o serviço de Estado de Componente Persistente para transmitir o estado de autenticação ao cliente, que é então fixado para o tempo de vida da CSR.PersistentAuthenticationStateProvider
(fonte de referência): para Blazor Web Apps que adotam a CSR. Esse é um AuthenticationStateProvider do lado do cliente que determina o estado de autenticação do usuário procurando dados persistentes na página quando ela foi renderizada no servidor. Esse estado de autenticação é fixo durante a vida útil da CSR. Se o usuário precisar fazer logon ou logout, será necessário recarregar a página inteira. Isso fornece apenas um nome de usuário e email para fins de exibição. Ele não inclui tokens que autenticam o servidor ao fazer solicitações subsequentes, que são tratadas separadamente usando um cookie que é incluído nas solicitaçõesHttpClient
ao servidor.
Observação
Os links de documentação para a fonte de referência do .NET geralmente carregam o branch padrão do repositório, que representa o desenvolvimento atual da próxima versão do .NET. Para selecionar uma marca para uma versão específica, use a lista suspensa para Alternar branches ou marcas. Para saber mais, confira Como selecionar uma marca de versão do código-fonte do ASP.NET Core (dotnet/AspNetCore.Docs #26205).
Scaffold Identity
Para obter mais informações sobre scaffolding Identity em um aplicativo Blazor do lado do servidor, confira Scaffolding Identity em projetos ASP.NET Core.
Faça scaffold Identity em um aplicativo Blazor do lado do servidor:
Declarações e tokens adicionais de provedores 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 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.
Injetar AuthenticationStateProvider
para serviços com escopo para 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 está inicializada corretamente.
Para acessar o AuthenticationStateProvider dentro de um serviço com escopo para um componente, injete o AuthenticationStateProvider com a diretiva @inject
ou o atributo [Inject]
e passe-o para o serviço como um parâmetro. Essa abordagem garante que a instância correta inicializada do AuthenticationStateProvider seja usada para cada instância de aplicativo de 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 com escopo. Em um aplicativo 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 arquivo Program
:
builder.Services.AddScoped<ExampleService>();
No Startup.ConfigureServices
do Startup.cs
:
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 inicializada doExampleService
que existe durante o 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);
}
}
@page "/inject-auth-state-provider"
@inject AuthenticationStateProvider AuthenticationStateProvider
@inherits OwningComponentBase
<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 diretrizes de OwningComponentBase em Injeção de dependência Blazor no ASP.NET Core.
Exibição de conteúdo não autorizado durante a pré-renderização com um AuthenticationStateProvider
personalizado
Para evitar a exibição de conteúdo não autorizado, por exemplo, conteúdo em um componente AuthorizeView
, durante a pré-renderização com um AuthenticationStateProvider
personalizado, adote uma das seguintes abordagens:
Implementar IHostEnvironmentAuthenticationStateProvider para o AuthenticationStateProvider personalizado e dar suporte à pré-renderização: para obter um exemplo de implementação de IHostEnvironmentAuthenticationStateProvider, confira a implementação Blazor da estrutura em ServerAuthenticationStateProvider
ServerAuthenticationStateProvider.cs
(fonte de referência).Observação
Os links de documentação para a fonte de referência do .NET geralmente carregam o branch padrão do repositório, que representa o desenvolvimento atual da próxima versão do .NET. Para selecionar uma marca para uma versão específica, use a lista suspensa para Alternar branches ou marcas. Para saber mais, confira Como selecionar uma marca de versão do código-fonte do ASP.NET Core (dotnet/AspNetCore.Docs #26205).
Desabilitar a pré-renderização: indique o modo de renderização com o parâmetro
prerender
definido comofalse
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 componenteApp
.Para aplicativos com base no modelo de projeto do Blazor Web App, a pré-renderização normalmente é desabilitada quando o componente
Routes
é usado no componenteApp
(Components/App.razor
):<Routes @rendermode="new InteractiveServerRenderMode(prerender: false)" />
Além disso, desabilite a pré-geração para o componente
HeadOutlet
:<HeadOutlet @rendermode="new InteractiveServerRenderMode(prerender: false)" />
Você também pode controlar de maneira seletiva o modo de renderização aplicado à instância do componente
Routes
. Por exemplo, confira Modos de renderização do ASP.NET Core Blazor.
Desabilitar a pré-renderização: abra o arquivo
_Host.cshtml
e altere o atributorender-mode
do Component Tag Helper para Server:<component type="typeof(App)" render-mode="Server" />
- Autenticar o usuário no servidor antes de iniciar o aplicativo: para adotar essa abordagem, o aplicativo deve responder à solicitação inicial de um usuário com a página ou exibição de logon baseada em Identity e impedir qualquer solicitação a pontos de extremidade Blazor até que haja a autenticação. Para obter mais informações, confira Criar um aplicativo ASP.NET Core com dados de 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 realmente não está autorizado a exibir o conteúdo.
Gerenciamento de estado do usuário
Apesar da palavra "estado" no nome, AuthenticationStateProvider não é para armazenar o 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 como ele está conectado.
A autenticação usa a mesma autenticação Identity do ASP.NET Core que os aplicativos Razor Pages e MVC. O estado do usuário armazenado para ASP.NET Core Identity flui sem Blazor adicionar código ao aplicativo. Siga as diretrizes nos artigos e tutoriais Identity do ASP.NET Core para que os recursos Identity entrem em vigor nas partes Blazor do aplicativo.
Para obter diretrizes sobre o gerenciamento de estado geral fora do ASP.NET Core Identity, consulte Gerenciamento de estado Blazor do ASP.NET Core.
Abstrações de segurança adicionais
Duas abstrações adicionais participam do gerenciamento do estado de autenticação:
ServerAuthenticationStateProvider (origem de referência): um AuthenticationStateProvider usado pela estrutura Blazor para obter o estado de autenticação do servidor.
RevalidatingServerAuthenticationStateProvider (origem de referência): uma classe base para serviços AuthenticationStateProvider usados pela estrutura Blazor para receber um estado de autenticação do ambiente de host e revalidar em intervalos regulares.
O intervalo padrão de revalidaçã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 o branch padrão do repositório, que representa o desenvolvimento atual da próxima versão do .NET. Para selecionar uma marca para uma versão específica, use a lista suspensa para Alternar branches ou marcas. Para saber mais, confira 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 na saída
O lado do servidor Blazor 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 usuário nas guias do navegador quando o usuário sair de uma guia, você deve implementar um RevalidatingServerAuthenticationStateProvider (fonte de referência) com um RevalidationInterval curto.
Observação
Os links de documentação para a fonte de referência do .NET geralmente carregam o branch padrão do repositório, que representa o desenvolvimento atual da próxima versão do .NET. Para selecionar uma marca para uma versão específica, use a lista suspensa para Alternar branches ou marcas. Para saber mais, confira Como selecionar uma marca de versão do código-fonte do ASP.NET Core (dotnet/AspNetCore.Docs #26205).
Duração da validade da URL de redirecionamento temporário
Esta seção aplica a Blazor Web Apps.
Use a opção RazorComponentsServiceOptions.TemporaryRedirectionUrlValidityDuration para obter ou definir o tempo de vida da validade da Proteção de dados do ASP.NET Core para URLs de redirecionamento temporário emitidas pela renderização do lado do servidor do Blazor. Eles são usados apenas transitoriamente, portanto, o tempo de vida só precisa ser longo o suficiente para que um cliente receba a URL e inicie a navegação nela. No entanto, também deve ser longo o suficiente para permitir a distorção do relógio entre os 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 de Blazor do lado do cliente
Em aplicativos do lado do cliente Blazor, as verificações de autenticação do lado do cliente podem ser ignoradas porque todo o código do lado do cliente pode ser modificado pelos usuários. Isso também ocorre com todas as tecnologias de aplicativo do lado do cliente, incluindo estruturas de SPA do JavaScript e aplicativos nativos em qualquer sistema operacional.
Adicione o seguinte:
Uma referência de pacote para o pacote NuGet
Microsoft.AspNetCore.Components.Authorization
.Observação
Para obter diretrizes sobre como adicionar pacotes a aplicativos .NET, consulte os artigos em Instalar e gerenciar pacotes no Fluxo de trabalho de consumo de pacotes (documentação do NuGet). Confirme as versões corretas de pacote em NuGet.org.
O namespace Microsoft.AspNetCore.Components.Authorization para o arquivo do aplicativo
_Imports.razor
.
Para lidar com a autenticação, use um serviço AuthenticationStateProvider interno ou personalizado.
Para mais informações sobre autenticação do lado do cliente, consulte ASP.NET Core Blazor WebAssembly seguro.
Serviço AuthenticationStateProvider
O AuthenticationStateProvider é o serviço subjacente usado pelo componente AuthorizeView e pelos serviços de autenticação em cascata para obter o estado de autenticação de um usuário.
O AuthenticationStateProvider é o serviço subjacente usado pelos componentes AuthorizeView e CascadingAuthenticationState para obter o estado de autenticação para um usuário.
Normalmente, você não usa o AuthenticationStateProvider diretamente. Use as abordagens do componente AuthorizeView
ou Task<AuthenticationState>
descritas mais adiante neste artigo. A principal desvantagem de usar o AuthenticationStateProvider diretamente é que o componente não será notificado automaticamente se os dados subjacentes do estado de autenticação forem alterados.
Para implementar um AuthenticationStateProvider personalizado, consulte Estado de autenticação do ASP.NET Core Blazor, que inclui diretrizes 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.
@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.";
}
}
}
Se user.Identity.IsAuthenticated
for true
e como o usuário é um ClaimsPrincipal, será possível enumerar as declarações e avaliar a associação nas funções.
Para obter mais informações sobre DI (injeção de dependência) e serviços, consulte Injeção de dependência de Blazor do ASP.NET Core e Injeção de dependência no ASP.NET Core. Para informações sobre como implementar um AuthenticationStateProvider personalizado, consulte Estado de autenticação do ASP.NET Core Blazor.
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 do procedimento, como ao realizar uma ação disparada pelo usuário, obtenha os dados de estado de autenticação definindo um parâmetro em cascata do tipo Task<
AuthenticationState>
, conforme demonstrado no 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.";
}
}
}
}
@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
, será possível enumerar as declarações e avaliar a associação nas funções.
Configurar o Task<
AuthenticationState>
parâmetro em cascata usando os serviços de AuthorizeRouteView e autenticação em cascata.
Ao criar 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. Um aplicativo Blazor do lado do cliente também inclui os registros de serviço necessários. Informações adicionais são apresentadas na seção Personalizar 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();
Configurar o Task<
AuthenticationState>
parâmetro em cascata usando os componentes AuthorizeRouteView e CascadingAuthenticationState.
Ao criar um aplicativo Blazor a partir de um dos modelos de projeto Blazor com a autenticação habilitada, o aplicativo inclui os componentes AuthorizeRouteView e CascadingAuthenticationState mostrados no exemplo a seguir. Um aplicativo Blazor do lado do cliente também inclui os registros de serviço necessários. Informações adicionais são apresentadas na seção Personalizar conteúdo não autorizado com o componente Router
.
<CascadingAuthenticationState>
<Router ...>
<Found ...>
<AuthorizeRouteView RouteData="routeData"
DefaultLayout="typeof(MainLayout)" />
...
</Found>
</Router>
</CascadingAuthenticationState>
Observação
Com a versão do ASP.NET Core 5.0.1 e para qualquer lançamento adicional do 5.x, o componente Router
inclui o parâmetro PreferExactMatches
definido como @true
. Para obter mais informações, consulte Migrar do ASP.NET Core 3.1 para o 5.0.
Em um aplicativo Blazor do cliente, adicione serviços de autorização ao arquivo Program
:
builder.Services.AddAuthorizationCore();
Em um aplicativo Blazor do cliente, adicione opções e serviços de autorização ao arquivo Program
:
builder.Services.AddOptions();
builder.Services.AddAuthorizationCore();
Em um aplicativo 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 o usuário é autenticado, as regras de autorização são aplicadas para controlar o que ele poderá fazer.
O acesso geralmente é concedido ou negado com base nos seguintes casos:
- Se o usuário está autenticado (conectado).
- Se o usuário está em uma função.
- Se o usuário tem uma declaração.
- Se uma política é atendida.
Todos esses conceitos são iguais no MVC do ASP.NET Core ou em aplicativos Razor Pages. Para obter mais informações sobre a segurança do ASP.NET Core, confira os artigos em Segurança e Identity do ASP.NET Core.
componente AuthorizeView
O componente AuthorizeView exibe de modo seletivo o conteúdo da interface do usuário, caso o usuário esteja autorizado. Essa abordagem é útil quando você precisa apenas exibir dados para o usuário e não precisa usar a identity dele na lógica de procedimento.
O componente expõe uma variável context
do tipo AuthenticationState (@context
na sintaxe Razor), que pode ser usada 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 AuthorizeView componente 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 HandleClick
método é associado apenas a um botão visível para usuários autorizados, mas nada impede a invocação desse método de outros lugares. Para garantir a segurança no nível do método, implemente a lógica de autorização adicional no próprio manipulador ou na API relevante.
Os componentes Razor de Blazor Web Apps nunca exibem o conteúdo <NotAuthorized>
quando a autorização falha no lado do servidor durante a SSR estática (renderização estática do lado do servidor). O pipeline do ASP.NET Core no 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 ASP.NET Core Blazor modos de renderização.
Aviso
A marcação do lado do cliente e os métodos associados a um AuthorizeView são protegidos apenas contra exibição e execução na interface do usuário renderizada em aplicativos Blazor do lado do cliente. Para proteger o conteúdo autorizado e os métodos seguros no Blazor do lado do cliente, o conteúdo geralmente é fornecido por uma chamada segura e autorizada da API Web para uma API do lado do servidor e nunca é armazenado no aplicativo. Para obter mais informações, consulte Chamar uma API Web de um aplicativo ASP.NET Core Blazor e Cenários de segurança adicionais do ASP.NET Core Blazor WebAssembly.
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 o acesso ou as opções da interface do usuário, são abordadas na seção Autorização.
Se as condições de autorização não forem especificadas, o AuthorizeView usará uma política padrão:
- Usuários autenticados (conectados) estão autorizados.
- Usuários não autenticados (não conectados) não estã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 remove apenas 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 em políticas
O componente AuthorizeView dá suporte à autorização baseada em funções ou baseada em políticas.
Para a autorização baseada em funções, 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 usuário 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 estabelece um Context
para o componente interno AuthorizeView para evitar uma colisão de contexto AuthenticationState. O contexto AuthenticationState é acessado no AuthorizeView externo com a abordagem padrão para acessar o contexto (@context.User
). O contexto é acessado no AuthorizeView internos 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 Policy parâmetro com um único nome de política:
<AuthorizeView Policy="Over21">
<p>You satisfy the 'Over21' policy.</p>
</AuthorizeView>
Caso o usuário precise cumprir uma das várias políticas, crie uma política que confirme que o usuário atende a outras políticas.
Caso o usuário precise atender a várias políticas simultaneamente, siga uma das seguintes abordagens:
Crie uma política para AuthorizeView que confirme que o usuário atende a várias outras políticas.
Aninhar 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 exige que os usuários tenham determinada declaração. Para obter mais informações, consulte Autorização baseada em política no ASP.NET Core.
Se Roles e Policy não forem especificados, o AuthorizeView usará a política padrão:
- Usuários autenticados (conectados) estão autorizados.
- Usuários não autenticados (não conectados) não estão autorizados.
Como as comparações de cadeia de caracteres do .NET diferenciam maiúsculas de minúsculas por padrão, a correspondência entre nomes de função e de política também diferencia maiúsculas de minúsculas. Por exemplo, Admin
(A
em maiúsculas) não é tratado como a mesma função que admin
(a
em minúsculas).
O caso Pascal normalmente é usado para nomes de função e política (por exemplo, BillingAdministrator
), mas o uso do caso Pascal não é um requisito estrito. Diferentes esquemas de uso de maiúsculas e minúsculas, como maiúsculas e minúsculas concatenadas, kebab e snake são permitidos. O uso de espaços em nomes de função e política é incomum, mas permitido pela estrutura. Por exemplo, billing administrator
é um formato incomum de função ou nome de política em aplicativos .NET, mas é uma função ou nome de política válido.
Conteúdo exibido durante a autenticação assíncrona
O Blazor permite que o estado de autenticação seja determinado de modo assíncrono. O cenário principal dessa abordagem ocorre em aplicativos Blazor do lado do cliente que fazem uma solicitação a um ponto de extremidade externo para autenticação.
Enquanto a autenticação estiver em andamento, AuthorizeView não exibirá nenhum conteúdo. Para exibir o conteúdo durante a autenticação, atribua 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>
Normalmente, essa abordagem não é aplicável a aplicativos Blazor do lado do servidor. Os aplicativos Blazor do lado do servidor ficam conhecendo o estado de autenticação assim que ele é estabelecido. O conteúdo Authorizing pode ser fornecido em um componente AuthorizeView do aplicativo, mas o conteúdo nunca é exibido.
Atributo [Authorize]
O atributo [Authorize]
está disponível em componentes Razor:
@page "/"
@attribute [Authorize]
You can only see this if you're signed in.
Importante
Use [Authorize]
somente em componentes @page
acessados por meio do roteador Blazor. A autorização é realizada apenas como um aspecto do roteamento e não para componentes filho renderizados dentro de uma página. Para autorizar a exibição de partes específicas dentro de uma página, use AuthorizeView.
O atributo [Authorize]
também dá suporte à autorização baseada em funções ou em políticas. Para a autorização baseada em funções, 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 a autorização baseada em políticas, use o parâmetro Policy:
@page "/"
@attribute [Authorize(Policy = "Over21")]
<p>You can only see this if you satisfy the 'Over21' policy.</p>
Se Roles e Policy não forem especificados, o [Authorize]
usará a política padrão:
- Usuários autenticados (conectados) estão autorizados.
- Usuários não autenticados (não conectados) não estão autorizados.
Quando o usuário não tem autorização o e se o aplicativo não personalizar conteúdo não autorizado com o componente Router
, a estrutura exibirá 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 Router.Found de 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 permite que a lógica personalizada tome decisões de autorização.
No exemplo a seguir, uma política 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 emvalue
. - 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 será atendida (retornartrue
) se o valor da cadeia de caracteres começar comEMP
. Caso contrário, declare que a política falhará (retornarfalse
).
No arquivo 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 simplificada, usada apenas para demonstrar o conceito com um exemplo em funcionamento. Para obter mais informações sobre como criar e configurar políticas de autorização, consulte Autorização baseada em política no ASP.NET Core.
No componente EditUser
a seguir, o recurso em /users/{id}/edit
tem um parâmetro de rota para o identificador do usuário ({id}
). O componente usa a política de autorização EditUser
anterior para determinar se o valor da rota para id
começa com EMP
. Se id
começar com EMP
, a política terá êxito e o acesso ao componente será autorizado. Se id
começar com um valor diferente 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; }
}
@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 o conteúdo não autorizado com o componente Router
O componente Router, em conjunto com o componente AuthorizeRouteView, permitirá que o aplicativo especifique o conteúdo personalizado se:
- O usuário não atender à condição
[Authorize]
aplicada ao componente. A marcação do elemento<NotAuthorized>
for exibida. O atributo[Authorize]
é abordado na seção Atributo[Authorize]
. - A autorização assíncrona estiver em andamento, o que geralmente significa que o processo de autenticação do usuário está em andamento. A marcação do elemento
<Authorizing>
for exibida.
Importante
Os recursos do roteador Blazor que exibem o conteúdo <NotAuthorized>
e <NotFound>
não estão operacionais durante a renderização estática do lado do servidor (SSR estática) porque o processamento de solicitações é totalmente tratado pelo processamento de solicitações do 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 ruins durante a SSR estática. Para obter mais informações, consulte ASP.NET Core Blazor modos de renderização.
<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 mencionado anteriormente requer o registro dos serviços de estado de autenticação em cascata no arquivo Program
do aplicativo:
builder.Services.AddCascadingAuthenticationState();
<CascadingAuthenticationState>
<Router ...>
<Found ...>
<AuthorizeRouteView ...>
<NotAuthorized>
...
</NotAuthorized>
<Authorizing>
...
</Authorizing>
</AuthorizeRouteView>
</Found>
</Router>
</CascadingAuthenticationState>
O conteúdo de NotFound, Authorized e NotAuthorized pode incluir itens arbitrários, como outros componentes interativos.
Se o conteúdo NotAuthorized não for especificado, o AuthorizeRouteView usará a mensagem de fallback a seguir:
Not authorized.
Um aplicativo criado a partir do modelo de projeto Blazor WebAssembly com a 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 de procedimento
Se for necessário que o aplicativo verifique as regras de autorização como parte da lógica de procedimento, use um parâmetro em cascata do tipo Task<
AuthenticationState>
para obter o ClaimsPrincipal do usuário. Task<
AuthenticationState>
pode ser combinado com outros serviços, como IAuthorizationService
, para avaliar as políticas.
No exemplo a seguir:
- O
user.Identity.IsAuthenticated
executa o código para usuários autenticados (conectados). - O
user.IsInRole("admin")
executa o código para usuários na função de "Administrador". - O
(await AuthorizationService.AuthorizeAsync(user, "content-editor")).Succeeded
executa o 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 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)
{
// ...
}
}
}
}
}
@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 problemas de erros
Erros comuns:
A autorização requer um parâmetro em cascata do tipo
Task<AuthenticationState>
. Considere usarCascadingAuthenticationState
para fornecer isso.O valor
null
é recebido paraauthenticationStateTask
Provavelmente, o projeto não foi criado usando um modelo Blazor do lado do servidor com a autenticação habilitada.
No .NET 7 ou versão anterior, encapsule um <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 versão 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();
O componente CascadingAuthenticationState (.NET 7 ou versão anterior) ou os serviços fornecidos pelo AddCascadingAuthenticationState (.NET 8 ou versão posterior) fornece o parâmetro Task<
AuthenticationState>
em cascata, que, por sua vez, recebe do serviço de injeção de dependência AuthenticationStateProvider subjacente.
PII (Informações de Identificação Pessoal)
A Microsoft usa a definição de 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 relacionada a uma pessoa natural identificada ou identificável. Uma pessoa natural identificável é aquela que pode ser identificada, direta ou indiretamente, com qualquer uma das seguintes opções:
- Nome
- Número de identificação
- Coordenadas de localização
- Identificador online
- Outros fatores específicos
- Físico
- Fisiológicos
- Genéticos
- Mentais (psicológicos)
- Económicos
- Cultural
- identity social
Recursos adicionais
- Lado do servidor e Blazor Web App recursos
- Início Rápido: Adicionar entrada com a Microsoft para um aplicativo Web do ASP.NET Core
- Início Rápido: Proteger uma API Web do ASP.NET Core com a plataforma de identity da Microsoft
- Configurar o ASP.NET Core para trabalhar com servidores proxy e balanceadores de carga: inclui diretrizes sobre:
- O uso de Middleware de Cabeçalhos Encaminhados para preservar informações do esquema HTTPS entre servidores proxy e redes internas.
- Cenários e casos de uso adicionais, incluindo configuração de esquema manual, solicitação de alterações de caminho para roteamento de solicitação correto e encaminhamento do esquema de solicitação para proxies reversos do Linux e não IIS.
- Documentação da plataforma de identity da Microsoft
- Tópicos de segurança do ASP.NET Core
- Configurar a Autenticação do Windows no ASP.NET Core
- Criar uma versão personalizada da biblioteca JavaScript Authentication.MSAL
- Awesome Blazor: links de exemplo da comunidade de autenticação
- Autenticação e autorização de Blazor Hybrid no ASP.NET Core
- Recursos do lado do servidor Blazor
- Início Rápido: Adicionar entrada com a Microsoft para um aplicativo Web do ASP.NET Core
- Início Rápido: Proteger uma API Web do ASP.NET Core com a plataforma de identity da Microsoft
- Configurar o ASP.NET Core para trabalhar com servidores proxy e balanceadores de carga: inclui diretrizes sobre:
- O uso de Middleware de Cabeçalhos Encaminhados para preservar informações do esquema HTTPS entre servidores proxy e redes internas.
- Cenários e casos de uso adicionais, incluindo configuração de esquema manual, solicitação de alterações de caminho para roteamento de solicitação correto e encaminhamento do esquema de solicitação para proxies reversos do Linux e não IIS.
- Documentação da plataforma de identity da Microsoft
- Tópicos de segurança do ASP.NET Core
- Configurar a Autenticação do Windows no ASP.NET Core
- Criar uma versão personalizada da biblioteca JavaScript Authentication.MSAL
- Awesome Blazor: links de exemplo da comunidade de autenticação