Как реализовать аутентификацию и авторизацию в Blazor?

Blazor Server

В Blazor Server состояние аутентификации передаётся с сервера напрямую. В Program.cs регистрируется Identity:

builder.Services.AddAuthentication(options =>
{
    options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
})
.AddCookie()
.AddOpenIdConnect("oidc", options =>
{
    options.Authority = "https://auth.example.com";
    options.ClientId = "blazor-app";
    options.ResponseType = "code";
    options.SaveTokens = true;
});

builder.Services.AddAuthorization();
builder.Services.AddCascadingAuthenticationState();

Аутентификация и авторизация в Blazor

Blazor полностью опирается на инфраструктуру ASP.NET Core для аутентификации и авторизации. Ключевой абстракцией является AuthenticationStateProvider, который предоставляет компонентам информацию о текущем пользователе через Task<AuthenticationState>.

Blazor WebAssembly

В WASM-варианте токен хранится в браузере. Устанавливается пакет Microsoft.AspNetCore.Components.WebAssembly.Authentication, а провайдер настраивается через AddOidcAuthentication:

// Program.cs (WASM)
builder.Services.AddOidcAuthentication(options =>
{
    options.ProviderOptions.Authority = "https://auth.example.com";
    options.ProviderOptions.ClientId = "blazor-wasm";
    options.ProviderOptions.ResponseType = "code";
    options.ProviderOptions.DefaultScopes.Add("openid");
    options.ProviderOptions.DefaultScopes.Add("profile");
    options.ProviderOptions.DefaultScopes.Add("api");
});

Защита маршрутов

В Routes.razor используйте AuthorizeRouteView вместо RouteView, чтобы маршруты, помеченные [Authorize], требовали входа:

<Router AppAssembly="typeof(App).Assembly">
    <Found Context="routeData">
        <AuthorizeRouteView RouteData="routeData"
                            DefaultLayout="typeof(MainLayout)">
            <NotAuthorized>
                <RedirectToLogin />
            </NotAuthorized>
        </AuthorizeRouteView>
    </Found>
</Router>

Авторизация в компонентах

Компонент AuthorizeView позволяет показывать разный UI в зависимости от состояния:

<AuthorizeView Roles="Admin">
    <Authorized>
        <p>Добро пожаловать, @context.User.Identity!.Name</p>
    </Authorized>
    <NotAuthorized>
        <p>Доступ запрещён.</p>
    </NotAuthorized>
</AuthorizeView>

В code-behind применяется атрибут [Authorize] с политиками:

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

// Регистрация политики
builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("RequireAdminRole", policy =>
        policy.RequireRole("Admin")
              .RequireClaim("department", "IT"));
});

Для программной проверки в компонентах используется IAuthorizationService:

@inject IAuthorizationService AuthService

var result = await AuthService.AuthorizeAsync(User, resource, "EditPolicy");
if (!result.Succeeded) { /* запрет */ }

Подводные камни

• В Blazor Server SignalR-соединение не переаутентифицируется автоматически при истечении cookie — нужно принудительно обновлять страницу или реализовывать кастомный AuthenticationStateProvider.
• В Blazor WASM токен хранится в SessionStorage или LocalStorage — при XSS атаке злоумышленник может его похитить; предпочтительнее BFF (Backend For Frontend) с httpOnly cookie.
• AuthorizeView скрывает UI, но не защищает API-эндпоинты — всегда проверяйте авторизацию на сервере.
• Роли и клеймы в WASM приходят из JWT; если токен устарел, context.User.IsInRole("Admin") вернёт false даже при успешной аутентификации.
• Атрибут [Authorize] на компоненте в Blazor Server обрабатывается на уровне маршрутизации, а не HTTP-middleware — нельзя полагаться на него без AuthorizeRouteView.
• При использовании Blazor Web App (.NET 8) режим рендеринга влияет на доступность HttpContext: в Interactive режимах он недоступен, берите данные через AuthenticationStateProvider.

• Путать authentication state и authorization views с похожим механизмом из другой версии или платформы.
• Игнорировать runtime-границы Blazor: lifecycle, DI scope, SQL translation, UI thread или platform API.
• Не обсуждать null/empty/error cases и поведение под нагрузкой.

• Кандидат объясняет authentication state и authorization views на конкретном примере, а не только определением.
• Указывает последствия для производительности, тестируемости и поддержки.
• Различает документированное поведение текущего стека и устаревшие практики.