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

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 renderização do lado do servidor (SSR) 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.

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, veja Scaffold ASP.NET Core Identity em um aplicativo Blazor do lado do servidor.

Suporte à anti-falsificação

O modelo Blazor:

• Adiciona serviços antifalsificação automaticamente quando AddRazorComponents é chamado no arquivo Program.
• Adiciona o middleware de proteção contra falsificação chamando UseAntiforgery em seu pipeline de processamento de solicitações no arquivo Program e requer proteção antifalsificação no endpoint 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 Visão geral dos formulários do ASP.NET CoreBlazor.

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 Chamar uma API Web de um aplicativo ASP.NET CoreBlazor.

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.

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 de Blazor Web Apps e à integração do Blazor com páginas MVC/Razor.
• Visão geral dos formulários do ASP.NET CoreBlazor: a seção de suporte contra falsificação do artigo refere-se ao suporte de antifalsificação de formulários.

Interface do usuário BlazorIdentity (contas individuais)

O Blazor dá suporte à geração de uma interface do usuário Blazor completa baseada no Identity quando você escolhe a opção de autenticação para Contas Individuais.

O modelo do Blazor Web App gera o código Identity para 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 IdentityRazor componentes e lógica relacionada para tarefas de autenticação de rotina, como entrar e sair dos usuários. Os Identity componentes também dão suporte a recursos avançados 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 do framework, acesse-os nas pastas Blazor e Identity da pasta Pages no projeto do servidor do modelo de projeto Shared (Components/Account repositório GitHub).

Quando você escolhe os modos de renderização Interativa WebAssembly ou Interativa Auto, o servidor lida com todas as solicitações de autenticação e autorização, e os componentes Identity são renderizados de forma estática no servidor no projeto principal do Blazor Web App.

A estrutura fornece um AuthenticationStateProvider personalizado nos projetos do servidor e do cliente (.Client) para transmitir o 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 obter mais informações, consulte a seção Gerenciar estado de autenticação no Blazor Web Apps.

Somente para soluções do Interactive Server, IdentityRevalidatingAuthenticationStateProvider (Components/Account/IdentityRevalidatingAuthenticationStateProvider.cs) no projeto de servidor do modelo de projeto Blazor Web App (dotnet/aspnetcore repositório GitHub), é um componente do lado do servidor AuthenticationStateProvider que revalida o carimbo de segurança para o usuário conectado a cada 30 minutos em que um circuito interativo está ativo.

Quando você escolhe os modos de renderização Interativa WebAssembly ou Interativa Auto, o servidor lida com todas as solicitações de autenticação e autorização, e os componentes Identity são renderizados de forma estática no servidor no projeto principal do Blazor Web App. O modelo de projeto inclui uma PersistentAuthenticationStateProvider classe (origem de referência) no .Client projeto 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 de Estado de Componente Persistente (PersistentComponentState) para pré-gerar o estado de autenticação e persistê-lo na página.

No projeto principal de um , o provedor de estado de autenticação é denominado na pasta do projeto servidor no modelo de projeto ( no repositório GitHub) (somente para soluções de interatividade do servidor) ou denominado (para soluções de interatividade WebAssembly ou Auto) na mesma pasta.

Blazor Identity depende DbContext de instâncias não criadas por uma fábrica, o que é intencional porque DbContext é suficiente para que os componentes do modelo de Identity 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 a persistência do estado pré-gerado, consulte ASP.NET Persistência de estado prerendered coreBlazor.

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, usando o serviço AuthenticationState (AuthenticationStateProvider), serializa o retornado pelo PersistentComponentState do lado do servidor:

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 (dotnet/aspnetcore Repositório GitHub): para Blazor Web Apps que adotam SSR (renderização interativa do lado do servidor) e 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 utiliza o serviço Estado do Componente Persistente para transferir o estado de autenticação para o cliente, permanecendo inalterado durante toda a duração da CSR.

• PersistingServerAuthenticationStateProvider (dotnet/aspnetcore Repositório GitHub): para Blazor Web Apps que adotam apenas 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 (dotnet/aspnetcore Repositório GitHub): para Blazor Web Apps que adotam 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ções HttpClient ao servidor.

Andaime Identity

Para obter mais informações sobre a estruturação Identity em um aplicativo servidor Blazor, consulte Estruturação Identity em projetos do ASP.NET Core.

Faça scaffold Identity em um aplicativo Blazor do lado do servidor:

• Sem autorização existente.
• Com autorização.

No arquivo Program:

builder.Services.AddScoped<ExampleService>();

No Startup.ConfigureServices do Startup.cs:

services.AddScoped<ExampleService>();

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

• Desabilitar a 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.

  Note

  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 com base no modelo de projeto do 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, 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, consulte os modos de renderização do ASP.NET CoreBlazor.

• Desabilitar a pré-renderização: abra o arquivo _Host.cshtml e altere o atributo render-mode do Component Tag Helper para Server:

  <component type="typeof(App)" render-mode="Server" />
  

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

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

Use a opção RazorComponentsServiceOptions.TemporaryRedirectionUrlValidityDuration para obter ou definir o período de validade da proteção de dados do ASP.NET Core para URLs de redirecionamento temporário emitidas pela renderização do lado do servidor 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));

Proteja dados em Blazor Web Apps com renderização automática interativa

Quando um adota renderização do lado do servidor (SSR) e renderização do lado do cliente (CSR) para componentes ou um aplicativo inteiro que especifica o "modo de renderização automática interativa" , a autorização para acessar componentes e dados é aplicada em dois locais. O componente restringe o acesso a si mesmo (e a todos os dados obtidos) quando renderizado no servidor em virtude de um atributo de autorização no arquivo de definição do componente (@attribute [Authorize]). Quando o componente é renderizado no cliente, o acesso aos dados é restrito por meio dos endpoints da API web do servidor chamados pelo cliente. É necessário ter cuidado ao proteger o acesso a dados em ambos os locais para impedir o acesso inadequado a dados.

Considere o cenário a seguir em que os dados meteorológicos seguros são exibidos por um componente. Demonstrações de algumas das abordagens a seguir podem ser avaliadas e testadas usando os BlazorWebAppEntra/BlazorWebAppEntraBffexemplos (.NET 9 ou posterior) ou os BlazorWebAppOidc/BlazorWebAppOidcBff exemplos (.NET 8 ou posterior) no Blazor repositório GitHub de exemplos (dotnet/blazor-samples) (como baixar).

O projeto cliente mantém uma classe WeatherForecast para armazenar dados meteorológicos:

public sealed class WeatherForecast(DateOnly date, int temperatureC, string summary)
{
    public DateOnly Date { get; set; } = date;
    public int TemperatureC { get; set; } = temperatureC;
    public string? Summary { get; set; } = summary;
    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
}

A interface de IWeatherForecaster do projeto cliente define um método GetWeatherForecastAsync para obter dados meteorológicos:

public interface IWeatherForecaster
{
    Task<IEnumerable<WeatherForecast>> GetWeatherForecastAsync();
}

O serviço de ClientWeatherForecaster do projeto do cliente implementa IWeatherForecaster. O método GetWeatherForecastAsync chama uma API da Web do projeto de servidor no endpoint /weather-forecast para dados meteorológicos.

internal sealed class ClientWeatherForecaster(HttpClient httpClient) 
    : IWeatherForecaster
{
    public async Task<IEnumerable<WeatherForecast>> GetWeatherForecastAsync() =>
        await httpClient.GetFromJsonAsync<WeatherForecast[]>("/weather-forecast") ??
            throw new IOException("No weather forecast!");
}

O projeto cliente mantém um componente Weather que:

• Impõe a autorização com um [Authorize] atributo.
• Usa o serviço de Estado de Componente Persistente (PersistentComponentState) para manter os dados de previsão do tempo quando o componente passa de SSR estático para interativo no servidor. Para obter mais informações, consulte ASP.NET Persistência de estado prerendered CoreBlazor.

@page "/weather"
@using Microsoft.AspNetCore.Authorization
@using BlazorWebAppEntra.Client.Weather
@attribute [Authorize]
@inject IWeatherForecaster WeatherForecaster

<PageTitle>Weather</PageTitle>

<h1>Weather</h1>

<p>This component demonstrates showing data.</p>

@if (Forecasts == null)
{
    <p><em>Loading...</em></p>
}
else
{
    <table class="table">
        <thead>
            <tr>
                <th>Date</th>
                <th aria-label="Temperature in Celsius">Temp. (C)</th>
                <th aria-label="Temperature in Fahrenheit">Temp. (F)</th>
                <th>Summary</th>
            </tr>
        </thead>
        <tbody>
            @foreach (var forecast in Forecasts)
            {
                <tr>
                    <td>@forecast.Date.ToShortDateString()</td>
                    <td>@forecast.TemperatureC</td>
                    <td>@forecast.TemperatureF</td>
                    <td>@forecast.Summary</td>
                </tr>
            }
        </tbody>
    </table>
}

@code {
    [PersistentState]
    public IEnumerable<WeatherForecast>? Forecasts { get; set; }

    protected override async Task OnInitializedAsync()
    {
        Forecasts ??= await WeatherForecaster.GetWeatherForecastAsync();
    }
}

@page "/weather"
@using Microsoft.AspNetCore.Authorization
@using BlazorWebAppEntra.Client.Weather
@attribute [Authorize]
@implements IDisposable
@inject PersistentComponentState ApplicationState
@inject IWeatherForecaster WeatherForecaster

<PageTitle>Weather</PageTitle>

<h1>Weather</h1>

<p>This component demonstrates showing data.</p>

@if (forecasts == null)
{
    <p><em>Loading...</em></p>
}
else
{
    <table class="table">
        <thead>
            <tr>
                <th>Date</th>
                <th aria-label="Temperature in Celsius">Temp. (C)</th>
                <th aria-label="Temperature in Fahrenheit">Temp. (F)</th>
                <th>Summary</th>
            </tr>
        </thead>
        <tbody>
            @foreach (var forecast in forecasts)
            {
                <tr>
                    <td>@forecast.Date.ToShortDateString()</td>
                    <td>@forecast.TemperatureC</td>
                    <td>@forecast.TemperatureF</td>
                    <td>@forecast.Summary</td>
                </tr>
            }
        </tbody>
    </table>
}

@code {
    private IEnumerable<WeatherForecast>? forecasts;
    private PersistingComponentStateSubscription persistingSubscription;

    protected override async Task OnInitializedAsync()
    {
        if (!ApplicationState.TryTakeFromJson<IEnumerable<WeatherForecast>>(
            nameof(forecasts), out var restoredData))
        {
            forecasts = await WeatherForecaster.GetWeatherForecastAsync();
        }
        else
        {
            forecasts = restoredData!;
        }

        // Call at the end to avoid a potential race condition at app shutdown
        persistingSubscription = ApplicationState.RegisterOnPersisting(PersistData);
    }

    private Task PersistData()
    {
        ApplicationState.PersistAsJson(nameof(forecasts), forecasts);

        return Task.CompletedTask;
    }

    void IDisposable.Dispose() => persistingSubscription.Dispose();
}

O projeto do servidor implementa IWeatherForecaster como ServerWeatherForecaster, o que gera e retorna dados meteorológicos por meio de seu GetWeatherForecastAsync método:

internal sealed class ServerWeatherForecaster() : IWeatherForecaster
{
    public readonly string[] summaries =
    [
        "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", 
        "Sweltering", "Scorching"
    ];

    public async Task<IEnumerable<WeatherForecast>> GetWeatherForecastAsync()
    {
        // Simulate asynchronous loading to demonstrate streaming rendering
        await Task.Delay(500);

        return Enumerable.Range(1, 5).Select(index =>
            new WeatherForecast
            (
                DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
                Random.Shared.Next(-20, 55),
                summaries[Random.Shared.Next(summaries.Length)]
            ))
        .ToArray();
    }
}

Se o aplicativo precisar chamar uma API Web externa para obter os dados meteorológicos, você poderá injetar um cliente HTTP (HttpClient) para solicitar os dados:

internal sealed class ServerWeatherForecaster(HttpClient httpClient, 
    IHttpContextAccessor httpContextAccessor) : IWeatherForecaster
{
    public async Task<IEnumerable<WeatherForecast>> GetWeatherForecastAsync()
    {
        var httpContext = httpContextAccessor.HttpContext ??
            throw new InvalidOperationException("No HttpContext!");
        var accessToken = await httpContext.GetTokenAsync("access_token") ??
            throw new InvalidOperationException("No access_token was saved");
        using var request = 
            new HttpRequestMessage(HttpMethod.Get, "/weather-forecast");
        request.Headers.Authorization = new("Bearer", accessToken);
        using var response = await httpClient.SendAsync(request);
        response.EnsureSuccessStatusCode();

        return await response.Content.ReadFromJsonAsync<WeatherForecast[]>() ??
            throw new IOException("No weather forecast!");
    }
}

Em outra abordagem, você pode injetar uma fábrica de clientes HTTP (IHttpClientFactory) no ServerWeatherForecaster e chamar uma API Web externa usando um cliente HTTP nomeado com um manipulador de token. Para obter mais informações, consulte Chamar uma API Web de um aplicativo ASP.NET CoreBlazor.

Se o aplicativo usar a plataforma de identidade Microsoft com os pacotes Microsoft Identity Web para o Microsoft Entra ID (consulte Chamar uma API da Web de um aplicativo ASP.NET Core Blazor), o ServerWeatherForecaster a seguir demonstra como fazer uma chamada para uma API da Web externa. O token de acesso é anexado automaticamente à solicitação.

internal sealed class ServerWeatherForecaster(IDownstreamApi downstreamApi) : IWeatherForecaster
{
    public async Task<IEnumerable<WeatherForecast>> GetWeatherForecastAsync()
    {
        using var response = await downstreamApi.CallApiForUserAsync("DownstreamApi",
            options =>
            {
                options.RelativePath = "/weather-forecast";
            });

        return await response.Content.ReadFromJsonAsync<WeatherForecast[]>() ??
            throw new IOException("No weather forecast!");
    }
}

Independentemente da abordagem adotada pelo ServerWeatherForecaster para obter os dados, o projeto do servidor mantém um ponto de extremidade seguro de API da Web para as chamadas de dados meteorológicos feitas pelos clientes. Esse endereço resulta em uma chamada ServerWeatherForecaster.GetWeatherForecastAsync no servidor:

app.MapGet("/weather-forecast", (
    [FromServices] IWeatherForecaster WeatherForecaster) =>
{
    return WeatherForecaster.GetWeatherForecastAsync();
}).RequireAuthorization();

Usando a abordagem anterior, há dois sistemas em vigor para fornecer dados meteorológicos seguros ao usuário:

• Quando o Weather componente é renderizado no servidor, o ServerWeatherForecaster método do GetWeatherForecastAsync serviço é usado diretamente para obter os dados meteorológicos. A segurança dos dados é imposta pelo atributo do [Authorize]componente. Em resumo, a segurança dos dados meteorológicos é imposta pelo componente.
• Quando o componente Weather é renderizado no cliente, o serviço ClientWeatherForecaster é usado para fazer uma chamada de API web ao ponto de extremidade seguro /weather-forecast que aplica o método de extensão RequireAuthorization. Se o usuário tiver autoridade para acessar dados meteorológicos, o endpoint usará o serviço ServerWeatherForecaster para chamar GetWeatherForecastAsync. Os dados são retornados ao cliente. Em resumo, a segurança dos dados meteorológicos é garantida pelo endpoint da API web do aplicativo de servidor.

A abordagem anterior funciona bem quando os requisitos de segurança da API Web correspondem aos requisitos de segurança do componente. Por exemplo, a mesma política de autorização pode ser aplicada ao ponto de extremidade da API Web e ao componente.

Cenários complexos exigem planejamento e implementação adicionais. Por exemplo, uma API Web do servidor que tem vários chamadores com permissões de acesso diferentes requer uma política de autorização mais sofisticada, uma ou mais políticas adicionais ou pontos de extremidade adicionais com requisitos de acesso diferentes.

À medida que você cria segurança em aplicativos que adotam a renderização automática interativa, lembre-se de que a segurança implementada para os pontos de extremidade da API Web do servidor não protege a implementação de serviço do servidor que é usada quando um componente é renderizado no servidor e acessa dados por meio do serviço. Avalie cuidadosamente a diferença entre acessar dados no servidor durante o SSR em vez de acessar os dados em uma solicitação de API Web do cliente durante a CSR. Aplique estrategicamente a segurança para evitar o acesso inadequado aos dados.

Exemplos no Blazor repositório GitHub de exemplos (dotnet/blazor-samples) (como baixar) que demonstram a abordagem descrita nesta seção:

• BlazorWebAppOidc
• BlazorWebAppOidcBff
• BlazorWebAppEntra
• BlazorWebAppEntraBff

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.

@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.";
        }
    }
}

@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.";
            }
        }
    }
}

Configure o Task<AuthenticationState>parâmetro em cascata usando o AuthorizeRouteView e os serviços de estado de 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();

Configure o Task<AuthenticationState>parâmetro em cascata usando os AuthorizeRouteView e CascadingAuthenticationState componentes.

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>

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

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

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 referente a 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 uma seção de 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 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, armazene value 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 (retornar true) se o valor da cadeia de caracteres começar com EMP. Caso contrário, declare que a política falhará (retornar false).

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; }
}

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

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.

@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)
                {
                    // ...
                }
            }
        }
    }
}

• Recursos Blazor Web App e no lado do servidor
  • 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 ASP.NET Core com a plataforma de identidade 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 manual de esquemas, alterações no caminho da solicitação para o roteamento correto da mesma, e encaminhamento do protocolo de solicitação para proxies reversos em Linux e outros que não utilizam IIS.
• Documentação da plataforma de identidade da Microsoft
  • Overview
  • Protocolos OAuth 2.0 e OpenID Connect na plataforma de identidade da Microsoft
  • Plataforma de identidade da Microsoft e fluxo de código de autorização do OAuth 2.0
  • Tokens de ID da plataforma de identidade da Microsoft
  • Tokens de acesso da plataforma de identidade da Microsoft
• tópicos de segurança do ASP.NET Core
• Configurar a Autenticação do Windows no ASP.NET Core
• IHttpContextAccessor/HttpContext em aplicativos do ASP.NET Core Blazor
• 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 do ASP.NET Core Blazor Hybrid

• 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 ASP.NET Core com a plataforma de identidade 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 manual de esquemas, alterações no caminho da solicitação para o roteamento correto da mesma, e encaminhamento do protocolo de solicitação para proxies reversos em Linux e outros que não utilizam IIS.
• Documentação da plataforma de identidade da Microsoft
  • Overview
  • Protocolos OAuth 2.0 e OpenID Connect na plataforma de identidade da Microsoft
  • Plataforma de identidade da Microsoft e fluxo de código de autorização do OAuth 2.0
  • Tokens de ID da plataforma de identidade da Microsoft
  • Tokens de acesso da plataforma de identidade da Microsoft
• tópicos de segurança do ASP.NET Core
• IHttpContextAccessor/HttpContext em aplicativos do ASP.NET Core Blazor
• 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