Zabezpečení ASP.NET Core Blazor WebAssembly s využitím ASP.NET Core Identity

Blazor WebAssembly Samostatné aplikace je možné zabezpečit pomocí ASP.NET Core Identity podle pokynů v tomto článku.

Koncové body pro registraci, přihlášení a odhlášení

Místo použití výchozího uživatelského rozhraní, které poskytuje ASP.NET Core Identity pro SPA a Blazor aplikace založené na Razor pages, zavolejte MapIdentityApi do back-endového rozhraní API koncové body JSON pro registraci a přihlašování uživatelů pomocí ASP.NET Core Identity. Identity Koncové body rozhraní API také podporují pokročilé funkce, jako je dvojúrovňové ověřování a ověřování e-mailů.

V klientovi zavolejte /register koncový bod a zaregistrujte uživatele s jeho e-mailovou adresou a heslem:

var result = await _httpClient.PostAsJsonAsync(
    "register", new
    {
        email,
        password
    });

V klientovi se přihlaste uživatele s ověřováním cookie pomocí koncového /login bodu s useCookies řetězcem dotazu nastaveným na true:

var result = await _httpClient.PostAsJsonAsync(
    "login?useCookies=true", new
    {
        email,
        password
    });

Rozhraní API back-endového serveru vytváří cookie ověřování pomocí volání AddIdentityCookies tvůrce ověřování:

builder.Services
    .AddAuthentication(IdentityConstants.ApplicationScheme)
    .AddIdentityCookies();

Ověřování tokenu

Pro nativní a mobilní scénáře, kdy někteří klienti nepodporují soubory cookie, poskytuje rozhraní API pro přihlášení parametr pro vyžádání tokenů.

Vystavil se vlastní token (který je proprietární pro platformu ASP.NET Core Identity ), který se dá použít k ověřování následných požadavků. Token by měl být předán v hlavičce Authorization jako nosný token. K dispozici je také obnovovací token. Tento token umožňuje aplikaci požádat o nový token, když vyprší platnost starého tokenu, aniž by uživatel museli znovu přihlásit.

Tokeny nejsou standardní webové tokeny JSON (JWT). Použití vlastních tokenů je záměrné, protože integrované Identity rozhraní API je určené především pro jednoduché scénáře. Možnost tokenu není určená jako plně funkční identity poskytovatel služeb nebo server tokenů, ale alternativou cookie k možnosti pro klienty, kteří nemůžou používat soubory cookie.

Následující doprovodné materiály začínají procesem implementace ověřování založeného na tokenech s přihlašovacím rozhraním API. K dokončení implementace se vyžaduje vlastní kód. Další informace najdete v tématu Použití Identity k zabezpečení back-endu webového rozhraní API pro služby SPA.

Místo rozhraní API back-endového serveru, které vytváří cookie ověřování pomocí volání AddIdentityCookies tvůrce ověřování, rozhraní API serveru nastaví ověřování nosného tokenu AddBearerToken pomocí metody rozšíření. Zadejte schéma nosných ověřovacích tokenů pomocí IdentityConstants.BearerScheme.

V Backend/Program.csčásti Změňte ověřovací služby a konfiguraci na následující:

builder.Services
    .AddAuthentication()
    .AddBearerToken(IdentityConstants.BearerScheme);

V BlazorWasmAuth/Identity/CookieAuthenticationStateProvider.cs, odebrat useCookies parametr řetězce dotazu v LoginAsync metodě CookieAuthenticationStateProvider:

- login?useCookies=true
+ login

V tomto okamžiku musíte zadat vlastní kód pro parsování AccessTokenResponse klienta a správu přístupových a obnovovacích tokenů. Další informace najdete v tématu Použití Identity k zabezpečení back-endu webového rozhraní API pro služby SPA.

Další Identity scénáře

Další Identity scénáře poskytované rozhraním API najdete v tématu Použití Identity k zabezpečení back-endu webového rozhraní API pro služby SPA:

• Zabezpečení vybraných koncových bodů
• Ověřování tokenu
• Dvojúrovňové ověřování (2FA)
• Kódy obnovení
• Správa uživatelských informací

Použití zabezpečených ověřovacích toků k zachování citlivých dat a přihlašovacích údajů

Ukázkové aplikace

V tomto článku slouží ukázkové aplikace jako referenční informace pro samostatné Blazor WebAssembly aplikace, které přistupují k ASP.NET Core Identity prostřednictvím back-endového webového rozhraní API. Ukázka obsahuje dvě aplikace:

• Backend: Aplikace back-endového webového rozhraní API, která udržuje uživatelské identity úložiště pro ASP.NET Core Identity.
• BlazorWasmAuth: Samostatná Blazor WebAssembly front-endová aplikace s ověřováním uživatelů.

Pomocí následujícího odkazu přejděte k ukázkovým aplikacím prostřednictvím složky nejnovější verze z kořenového adresáře úložiště. Ukázky jsou k dispozici pro .NET 8 nebo novější. README Postup spuštění ukázkových aplikací najdete ve BlazorWebAssemblyStandaloneWithIdentity složce ve složce.

Zobrazení nebo stažení ukázkového kódu (postup stažení)

Balíčky a kód aplikace webového rozhraní API back-endu

Aplikace back-endového webového rozhraní API udržuje uživatelské identity úložiště pro ASP.NET Core Identity.

Balíčky

Aplikace používá následující balíčky NuGet:

• Microsoft.AspNetCore.Identity.EntityFrameworkCore
• Microsoft.EntityFrameworkCore.InMemory
• NSwag.AspNetCore

Pokud vaše aplikace používá jiného EF Core zprostředkovatele databáze, než je poskytovatel v paměti, nevytvádejte v aplikaci odkaz na balíček pro Microsoft.EntityFrameworkCore.InMemory.

V souboru projektu aplikace (.csproj) je nakonfigurovaná invariantní globalizace .

Ukázkový kód aplikace

Nastavení aplikace konfiguruje back-endové a front-endové adresy URL:

• Backend aplikace (BackendUrl): https://localhost:7211
• BlazorWasmAuth aplikace (FrontendUrl): https://localhost:7171

Soubor Backend.http lze použít k testování žádosti o data o počasí. Upozorňujeme, že BlazorWasmAuth aplikace musí být spuštěná, aby otestovala koncový bod, a koncový bod je pevně zakódovaný do souboru. Další informace naleznete v tématu Použití souborů .http v sadě Visual Studio 2022.

Následující nastavení a konfigurace se nacházejí v souboru aplikaceProgram.

Uživatel identity s cookie ověřováním se přidá voláním AddAuthentication a AddIdentityCookies. Služby pro kontroly autorizace se přidají voláním .AddAuthorizationBuilder

Doporučuje se pouze pro ukázky, aplikace používá EF Core zprostředkovatele databáze v paměti pro registraci kontextu databáze (AddDbContext). Zprostředkovatel databáze v paměti usnadňuje restartování aplikace a otestování toků registrace a přihlášení uživatelů. Každé spuštění začíná novou databází, ale aplikace obsahuje ukázkový kód testovacího uživatele, který je popsán dále v tomto článku. Pokud se databáze změní na SQLite, uživatelé se ukládají mezi relacemi, ale databázi je potřeba vytvořit prostřednictvím migrací, jak je znázorněno v úvodním EF Core kurzu†. Pro produkční kód můžete použít další relační zprostředkovatele, jako je SQL Server.

Nakonfigurujte Identity použití EF Core databáze a zveřejnění Identity koncových bodů prostřednictvím volání , AddIdentityCoreAddEntityFrameworkStoresa AddApiEndpoints.

Vytvoří se zásada sdílení prostředků mezi zdroji (CORS), která umožňuje žádosti z front-endových a back-endových aplikací. Náhradní adresy URL jsou nakonfigurované pro zásady CORS, pokud je nastavení aplikace neposkytuje:

• Backend aplikace (BackendUrl): https://localhost:5001
• BlazorWasmAuth aplikace (FrontendUrl): https://localhost:5002

Služby a koncové body pro Swagger/OpenAPI jsou součástí dokumentace k webovému rozhraní API a testování vývoje. Další informace o NSwag najdete v tématu Začínáme se službou NSwag a ASP.NET Core.

Deklarace identity role uživatele se odesílají z minimálního rozhraní API na koncovém /roles bodu.

Trasy se mapují pro Identity koncové body voláním MapIdentityApi<AppUser>().

Koncový bod odhlášení (/Logout) je nakonfigurovaný v kanálu middlewaru pro odhlášení uživatelů.

Pokud chcete zabezpečit koncový bod, přidejte do definice trasy metodu RequireAuthorization rozšíření. Pro kontroler přidejte [Authorize] atribut do kontroleru nebo akce.

Další informace o základních vzorech pro inicializaci a konfiguraci DbContext instance naleznete v tématu Životnost, Konfigurace a Inicializace DbContext v EF Core dokumentaci.

Balíčky a kód samostatné Blazor WebAssembly aplikace front-endu

Samostatná Blazor WebAssembly front-endová aplikace předvádí ověřování uživatelů a autorizaci pro přístup k privátní webové stránce.

Balíčky

Aplikace používá následující balíčky NuGet:

• Microsoft.AspNetCore.Components.WebAssembly.Authentication
• Microsoft.Extensions.Http
• Microsoft.AspNetCore.Components.WebAssembly
• Microsoft.AspNetCore.Components.WebAssembly.DevServer

Ukázkový kód aplikace

Složka Models obsahuje modely aplikace:

• FormResult (Identity/Models/FormResult.cs): Odpověď na přihlášení a registraci.
• UserInfo (Identity/Models/UserInfo.cs): Informace o uživateli z identity koncového bodu pro navázání deklarací identity.

Rozhraní IAccountManagement (Identity/CookieHandler.cs) poskytuje služby správy účtů.

Třída () zpracovává stav ověřování cookiena základě a poskytuje implementace služby správy účtů popsané rozhranímIAccountManagement.Identity/CookieAuthenticationStateProvider.csCookieAuthenticationStateProvider Metoda LoginAsync explicitně povolí cookie ověřování prostřednictvím useCookies řetězcové hodnoty truedotazu . Třída také spravuje vytváření deklarací identity rolí pro ověřené uživatele.

Třída CookieHandler (Identity/CookieHandler.cs) zajišťuje, že cookie se přihlašovací údaje odesílají s každou žádostí do back-endového webového rozhraní API, které zpracovává Identity a udržuje Identity úložiště dat.

Poskytuje wwwroot/appsettings.file koncové body adresy URL back-endu a front-endu.

Komponenta App zveřejňuje stav ověřování jako kaskádový parametr. Další informace najdete v tématu ASP.NET ověřování a autorizace jádraBlazor.

Komponenta a NavMenu komponentaMainLayout používají komponentu AuthorizeView k selektivnímu zobrazení obsahu na základě stavu ověřování uživatele.

Následující komponenty zpracovávají běžné úlohy ověřování uživatelů a využívají IAccountManagement služby:

• Register component (Components/Identity/Register.razor)
• Login component (Components/Identity/Login.razor)
• Logout component (Components/Identity/Logout.razor)

Komponenta PrivatePage (Components/Pages/PrivatePage.razor) vyžaduje ověření a zobrazuje deklarace identity uživatele.

Služby a konfigurace jsou k dispozici v Program souboru (Program.cs):

• Obslužná rutina cookie je zaregistrovaná jako služba s vymezeným oborem.
• Autorizační služby jsou zaregistrované.
• Vlastní zprostředkovatel stavu ověřování je zaregistrovaný jako služba s vymezeným oborem.
• Rozhraní pro správu účtů (IAccountManagement) je zaregistrované.
• Základní adresa URL hostitele je nakonfigurovaná pro zaregistrovanou instanci klienta HTTP.
• Základní back-endová adresa URL je nakonfigurovaná pro zaregistrovanou instanci klienta HTTP, která se používá k interakci s back-endovým webovým rozhraním API. Klient HTTP používá obslužnou rutinu cookie k zajištění, že cookie se přihlašovací údaje odesílají s každou žádostí.

Zavolejte AuthenticationStateProvider.NotifyAuthenticationStateChanged , když se změní stav ověřování uživatele. Příklad najdete v LoginAsync tématu a LogoutAsync metody CookieAuthenticationStateProvider třídy (Identity/CookieAuthenticationStateProvider.cs).

Testování ukázky počátečního nastavení uživatele

Třída SeedData (SeedData.cs) ukazuje, jak vytvořit testovací uživatele pro vývoj. Testovací uživatel s názvem Leela se přihlásí k aplikaci pomocí e-mailové adresy leela@contoso.com. Heslo uživatele je nastavené na Passw0rd!. Leela má udělené Administrator role a Manager role pro autorizaci, které uživateli umožňují přístup na stránku manažera, /private-manager-page ale ne na stránce editoru na /private-editor-pageadrese .

if (builder.Environment.IsDevelopment())
{
    await using var scope = app.Services.CreateAsyncScope();
    await SeedData.InitializeAsync(scope.ServiceProvider);
}

Role

Kvůli problému s návrhem architektury (dotnet/aspnetcore #50037) se deklarace identity rolí neodesílají zpět z manage/info koncového BlazorWasmAuth bodu, aby se vytvořily deklarace identity uživatelů pro uživatele aplikace. Deklarace identity rolí se spravují nezávisle prostřednictvím samostatného požadavku v GetAuthenticationStateAsync metodě třídy (Identity/CookieAuthenticationStateProvider.cs) po ověření uživatele v Backend projektu.CookieAuthenticationStateProvider

V této části CookieAuthenticationStateProviderse do koncového Backend bodu projektu rozhraní API serveru vytvoří /roles žádost o role. Odpověď se načte do řetězce voláním ReadAsStringAsync(). JsonSerializer.Deserialize deserializuje řetězec do vlastního RoleClaim pole. Nakonec se deklarace identity přidají do kolekce deklarací identity uživatele.

V souboru rozhraní API Program serveru spravuje /roles koncové body minimální rozhraní API.Backend RoleClaimType Deklarace identity jsou vybrány do anonymního typu a serializovány pro návrat do BlazorWasmAuth projektu s TypedResults.Json.

Koncový bod rolí vyžaduje autorizaci voláním RequireAuthorization. Pokud se rozhodnete nepoužívat minimální rozhraní API ve prospěch kontrolerů pro zabezpečené koncové body rozhraní API serveru, nezapomeňte nastavit [Authorize] atribut pro kontrolery nebo akce.

Hostování mezi doménou (konfigurace stejné lokality)

Ukázkové aplikace jsou nakonfigurované pro hostování obou aplikací ve stejné doméně. Pokud aplikaci hostujete Backend v jiné doméně než BlazorWasmAuth aplikace, odkomentujte kód, který konfiguruje cookie (ConfigureApplicationCookie) v Backend souboru aplikace Program . Výchozí hodnoty jsou:

• Režim stejného webu: SameSiteMode.Lax
• Zásady zabezpečení: CookieSecurePolicy.SameAsRequest

Změňte hodnoty na:

• Režim stejného webu: SameSiteMode.None
• Zásady zabezpečení: CookieSecurePolicy.Always

- options.Cookie.SameSite = SameSiteMode.Lax;
- options.Cookie.SecurePolicy = CookieSecurePolicy.SameAsRequest;
+ options.Cookie.SameSite = SameSiteMode.None;
+ options.Cookie.SecurePolicy = CookieSecurePolicy.Always;

Další informace o nastavení stejného webu cookie najdete v následujících zdrojích informací:

• Set-Cookie: SameSite=<samesite-value> (Dokumentace k MDN)
• Cookies: Mechanismus správy stavu HTTP (koncept 6265 RFC, oddíl 4.1)

Podpora antiforgery

Pouze koncový bod odhlášení (/logout) v Backend aplikaci vyžaduje pozornost, aby se snížila hrozba typu CsrF (Cross-Site Request Forgery).

Koncový bod odhlášení zkontroluje prázdný text, aby se zabránilo útokům CSRF. Vyžadováním textu musí být požadavek proveden z JavaScriptu, což je jediný způsob, jak získat přístup k ověřování cookie. Koncový bod odhlášení není přístupný pomocí post založeného na formuláři. Tím zabráníte škodlivému webu v odhlášení uživatele.

Koncový bod je navíc chráněný autorizací (RequireAuthorization), aby se zabránilo anonymnímu přístupu.

Klientská BlazorWasmAuth aplikace je jednoduše nutná k předání prázdného objektu {} v textu požadavku.

Mimo koncový bod odhlášení je antiforgery zmírnění rizik vyžadováno pouze při odesílání dat formuláře na server kódovaný jako application/x-www-form-urlencoded, multipart/form-datanebo text/plain. Blazor ve většině případů spravuje zmírnění rizik CSRF pro formuláře. Další informace najdete v tématu ASP.NET Blazor Základní ověřování a autorizace a přehled formulářů ASP.NET CoreBlazor.

Požadavky na jiné koncové body rozhraní API serveru (webové rozhraní API) s kódovaným obsahem a povoleným application/jsonCORS nevyžadují ochranu CSRF. Proto se pro Backend koncový bod zpracování dat (/data-processing) aplikace nevyžaduje žádná ochrana CSRF. Koncový bod role (/roles) nepotřebuje ochranu CSRF, protože se jedná o koncový bod GET, který neupravuje žádný stav.

Odstraňování potíží

Protokolování

Pokud chcete povolit protokolování ladění nebo trasování pro Blazor WebAssembly ověřování, přečtěte si téma ASP.NET protokolování coreBlazor.

Běžné chyby

Zkontrolujte konfiguraci každého projektu. Ověřte správnost adres URL:

• Backend projekt
  • appsettings.json
    • BackendUrl
    • FrontendUrl
  • Backend.http: Backend_HostAddress
• BlazorWasmAuth projekt: wwwroot/appsettings.json
  • BackendUrl
  • FrontendUrl

Pokud se konfigurace zobrazí správně:

• Analyzujte protokoly aplikace.

• Prozkoumejte síťový provoz mezi BlazorWasmAuth aplikací a Backend aplikací pomocí vývojářských nástrojů prohlížeče. Často se po provedení požadavku klientovi vrátí přesná chybová zpráva nebo zpráva s povědomím o příčině problému. Vývojářské nástroje pokyny najdete v následujících článcích:

• Google Chrome (dokumentace Google)

• Microsoft Edge

• Mozilla Firefox (dokumentace k Mozilla)

Tým dokumentace reaguje na zpětnou vazbu a chyby v článcích. Otevřete problém pomocí odkazu Otevřít problém s dokumentací v dolní části článku. Tým nemůže poskytovat podporu produktů. K dispozici je několik veřejných fór podpory, která vám pomůžou s řešením potíží s aplikací. Doporučujeme následující:

• Stack Overflow (značka: blazor)
• ASP.NET Core Slack Team
• Blazor Gitter

Předchozí fóra nejsou vlastněna ani řízena Společností Microsoft.

V případě zpráv o chybách rozhraní bez zabezpečení, nerozlišujících a nedůvěryhodných reprodukovatelných chyb otevřete problém s produktovou jednotkou ASP.NET Core. Neotevírejte problém s produktovou jednotkou, dokud důkladně neprošetříte příčinu problému a nemůžete ho vyřešit sami a s pomocí komunity na veřejném fóru podpory. Produktová jednotka nedokáže řešit potíže s jednotlivými aplikacemi, které jsou poškozené kvůli jednoduché chybné konfiguraci nebo případům použití zahrnujícím služby třetích stran. Pokud je sestava citlivá nebo důvěrná v povaze nebo popisuje potenciální chybu zabezpečení v produktu, který může cyberattackers zneužít, přečtěte si téma Hlášení problémů se zabezpečením a chyb (dotnet/aspnetcore úložiště GitHub).

Soubory cookie a data webu

Soubory cookie a data webu se můžou uchovávat v aktualizacích aplikací a kolidovat s testováním a odstraňováním potíží. Při provádění změn kódu aplikace, změn uživatelského účtu nebo změn konfigurace aplikace zrušte zaškrtnutí následujících pokynů:

• Soubory cookie přihlašování uživatelů
• Soubory cookie aplikace
• Uložená a uložená data lokality v mezipaměti

Jedním z přístupů k tomu, aby se zabránilo zasahování souborů cookie a dat webu do testování a řešení potíží, je:

• Konfigurace prohlížeče
  • K testování můžete použít prohlížeč, který můžete nakonfigurovat tak, aby při každém zavření prohlížeče odstranil všechna cookie data a data webu.
  • Ujistěte se, že je prohlížeč zavřený ručně nebo integrované vývojové prostředí (IDE) pro všechny změny aplikace, testovacího uživatele nebo konfigurace poskytovatele.
• Pomocí vlastního příkazu otevřete prohlížeč v režimu InPrivate nebo Incognito v sadě Visual Studio:
  • V dialogovém okně Spustit v sadě Visual Studio otevřete dialogové okno Procházet.
  • Vyberte tlačítko Přidat.
  • Do pole Program zadejte cestu k prohlížeči. Následující spustitelné cesty jsou typická umístění instalace pro Windows 10. Pokud je váš prohlížeč nainstalovaný v jiném umístění nebo nepoužíváte Windows 10, zadejte cestu ke spustitelnému souboru prohlížeče.
    • Microsoft Edge: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
    • Google Chrome: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
    • Mozilla Firefox: C:\Program Files\Mozilla Firefox\firefox.exe
  • V poli Argumenty zadejte možnost příkazového řádku, kterou prohlížeč používá k otevření v režimu InPrivate nebo Anonymní režim. Některé prohlížeče vyžadují adresu URL aplikace.
    • Microsoft Edge: Použijte -inprivate.
    • Google Chrome: Použijte --incognito --new-window {URL}, kde {URL} zástupný symbol je adresa URL k otevření (například https://localhost:5001).
    • Mozilla Firefox: Použijte -private -url {URL}, kde {URL} zástupný symbol je adresa URL k otevření (například https://localhost:5001).
  • Do pole Popisný název zadejte název. Například Firefox Auth Testing.
  • Vyberte tlačítko OK.
  • Pokud se chcete vyhnout výběru profilu prohlížeče pro každou iteraci testování pomocí aplikace, nastavte profil jako výchozí tlačítkem Nastavit jako výchozí .
  • Ujistěte se, že integrované vývojové prostředí (IDE) zavřel prohlížeč pro všechny změny aplikace, testovacího uživatele nebo konfigurace poskytovatele.

Upgrady aplikací

Funkční aplikace může selhat okamžitě po upgradu sady .NET Core SDK na vývojovém počítači nebo změně verzí balíčků v aplikaci. V některých případech můžou inkoherentní balíčky přerušit aplikaci při provádění hlavních upgradů. Většinu těchto problémů je možné vyřešit pomocí těchto pokynů:

1. Vymažte mezipaměti balíčků NuGet místního systému spuštěním dotnet nuget locals all --clear z příkazového prostředí.
2. Odstraňte složky a obj složky projektubin.
3. Obnovte a znovu sestavte projekt.
4. Před opětovným nasazením aplikace odstraňte všechny soubory ve složce nasazení na serveru.

Kontrola deklarací identity uživatele

Při řešení problémů s deklaracemi identity uživatelů je možné použít následující UserClaims komponentu přímo v aplikacích nebo sloužit jako základ pro další přizpůsobení.

UserClaims.razor:

@page "/user-claims"
@using System.Security.Claims
@attribute [Authorize]

<PageTitle>User Claims</PageTitle>

<h1>User Claims</h1>

**Name**: @AuthenticatedUser?.Identity?.Name

<h2>Claims</h2>

@foreach (var claim in AuthenticatedUser?.Claims ?? Array.Empty<Claim>())
{
    <p class="claim">@(claim.Type): @claim.Value</p>
}

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

    public ClaimsPrincipal? AuthenticatedUser { get; set; }

    protected override async Task OnInitializedAsync()
    {
        if (AuthenticationState is not null)
        {
            var state = await AuthenticationState;
            AuthenticatedUser = state.User;
        }
    }
}

Další materiály

• identity Novinky v .NET 8
• AuthenticationStateProvider služba
• Vyjednávání mezi zdroji na straně SignalR klienta pro ověřování