Skydda en fristående ASP.NET Core Blazor WebAssembly-app med autentiseringsbiblioteket

Den här artikeln beskriver hur du skyddar en ASP.NET Core Blazor WebAssembly fristående app med Blazor WebAssembly-autentiseringsbiblioteket.

Blazor WebAssembly-autentiseringsbiblioteket (Authentication.js) stöder endast Proof Key for Code Exchange (PKCE) auktoriseringskodflöde via Microsoft Authentication Library (MSAL, msal.js). Om du vill implementera andra beviljandeflöden kan du komma åt MSAL-vägledningen för att implementera MSAL direkt, men vi stöder inte eller rekommenderar inte användning av andra beviljandeflöden än PKCE för Blazor appar.

Följ inte riktlinjerna i det här avsnittet för Microsoft Entra (ME-ID) och Azure Active Directory B2C (AAD B2C). Se Skydda en fristående ASP.NET Core Blazor WebAssembly-app med Microsoft Entra ID eller Skydda en fristående ASP.NET Core Blazor WebAssembly-app med Azure Active Directory B2C.

För ytterligare täckning av säkerhetsscenarier efter att ha läst den här artikeln, se ASP.NET Core Blazor WebAssembly ytterligare säkerhetsscenarier.

Walkthrough

Underavsnitten i genomgången förklarar hur du:

• Registrera en app
• Skapa Blazor-appen
• Kör appen

Registrera en app

Registrera en app med en OpenID Connect (OIDC)Identity Provider (IP) enligt den vägledning som tillhandahålls av IP:s förvaltare.

Registrera följande information:

• Myndighet (till exempel https://accounts.google.com/).
• Program-ID (klient) (till exempel 2...7-e...q.apps.googleusercontent.com).
• Ytterligare IP-konfiguration (se IP-dokumentationen).

Skapa Blazor-appen

Om du vill skapa en fristående Blazor WebAssembly app som använder Microsoft.AspNetCore.Components.WebAssembly.Authentication-biblioteket följer du vägledningen för val av verktyg. Om du lägger till stöd för autentisering kan du läsa avsnittet delar av appen i den här artikeln för vägledning om hur du konfigurerar appen.

dotnet new blazorwasm -au Individual -o {PROJECT NAME}

Konfigurera appen

Konfigurera appen enligt IP-adressens vägledning. Appen kräver minst konfigurationsinställningarna Local:Authority och Local:ClientId i appens wwwroot/appsettings.json-fil:

{
  "Local": {
    "Authority": "{AUTHORITY}",
    "ClientId": "{CLIENT ID}"
  }
}

Google OAuth 2.0 OIDC-exempel för en app som körs på localhost-adressen på port 5001:

{
  "Local": {
    "Authority": "https://accounts.google.com/",
    "ClientId": "2...7-e...q.apps.googleusercontent.com",
    "PostLogoutRedirectUri": "https://localhost:5001/authentication/logout-callback",
    "RedirectUri": "https://localhost:5001/authentication/login-callback",
    "ResponseType": "code"
  }
}

Omdirigerings-URI :n (https://localhost:5001/authentication/login-callback) är registrerad i Google API-konsolen i Credentials>{NAME}>Auktoriserade omdirigerings-URI:er, där {NAME} är appens klientnamn i OAuth 2.0-klient-ID:n applista för Google API:er-konsolen.

Kör appen

Använd någon av följande metoder för att köra appen:

• Visual Studio
  • Välj knappen Kör.
  • Använd Felsök>Starta felsökning från menyn.
  • Tryck på F5.
• .NET CLI-kommandogränssnitt: Kör kommandot dotnet watch (eller dotnet run) från appens mapp.

Delar av appen

I det här avsnittet beskrivs de delar av en app som genereras från Blazor WebAssembly-projektmallen och hur appen konfigureras. Det finns ingen specifik vägledning att följa i det här avsnittet för ett grundläggande arbetsprogram om du har skapat appen med hjälp av vägledningen i avsnittet Genomgång. Vägledningen i det här avsnittet är användbar för att uppdatera en app för att autentisera och auktorisera användare. En alternativ metod för att uppdatera en app är dock att skapa en ny app från vägledningen i avsnittet Genomgång och flytta appens komponenter, klasser och resurser till den nya appen.

Autentiseringspaket

När en app skapas för att använda enskilda konton får appen automatiskt en paketreferens för Microsoft.AspNetCore.Components.WebAssembly.Authentication paketet. Paketet innehåller en uppsättning primitiver som hjälper appen att autentisera användare och hämta token för att anropa skyddade API:er.

Om du lägger till autentisering i en app lägger du till Microsoft.AspNetCore.Components.WebAssembly.Authentication-paketet manuellt i appen.

Stöd för autentiseringstjänst

Stöd för att autentisera användare med hjälp av OpenID Connect (OIDC) är registrerat i tjänstbehållaren med tilläggsmetoden AddOidcAuthentication, som tillhandahålls av Microsoft.AspNetCore.Components.WebAssembly.Authentication-paketet.

Metoden AddOidcAuthentication accepterar ett återanrop för att konfigurera de parametrar som krävs för att autentisera en app med hjälp av OIDC. De värden som krävs för att konfigurera appen kan hämtas från den OIDC-kompatibla IP-adressen. Hämta värdena när du registrerar appen, vilket vanligtvis sker i deras onlineportal.

För en ny app anger du värden för platshållarna {AUTHORITY} och {CLIENT ID} i följande konfiguration. Ange andra konfigurationsvärden som krävs för användning med appens IP-adress. Exemplet är för Google, som kräver PostLogoutRedirectUri, RedirectUrioch ResponseType. Om du lägger till autentisering i en app lägger du manuellt till följande kod och konfiguration i appen med värden för platshållarna och andra konfigurationsvärden.

I filen Program:

builder.Services.AddOidcAuthentication(options =>
{
    builder.Configuration.Bind("Local", options.ProviderOptions);
});

wwwroot/appsettings.json konfiguration

Konfigurationen tillhandahålls av wwwroot/appsettings.json-filen:

{
  "Local": {
    "Authority": "{AUTHORITY}",
    "ClientId": "{CLIENT ID}"
  }
}

Åtkomsttokensomfång

Mallen Blazor WebAssembly konfigurerar automatiskt standardomfattningar för openid och profile.

Mallen Blazor WebAssembly konfigurerar inte automatiskt appen för att begära en åtkomsttoken för ett säkert API. Om du vill etablera en åtkomsttoken som en del av inloggningsflödet lägger du till omfånget i standardtokenomfången för OidcProviderOptions. Om du lägger till autentisering i en app lägger du till följande kod manuellt och konfigurerar omfångs-URI:n.

I filen Program:

builder.Services.AddOidcAuthentication(options =>
{
    ...
    options.ProviderOptions.DefaultScopes.Add("{SCOPE URI}");
});

Mer information finns i följande avsnitt i artikeln Ytterligare scenarier:

• Begär ytterligare åtkomsttoken
• Koppla tokenen till utgående begäranden

Importerar fil

Namnområdet Microsoft.AspNetCore.Components.Authorization görs tillgängligt i hela appen via _Imports.razor-filen:

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

Indexsida

Sidan Index (wwwroot/index.html) innehåller ett skript som definierar AuthenticationService i JavaScript. AuthenticationService hanterar lågnivåinformationen för OIDC-protokollet. Appen anropar internt metoder som definierats i skriptet för att utföra autentiseringsåtgärderna.

<script src="_content/Microsoft.AspNetCore.Components.WebAssembly.Authentication/AuthenticationService.js"></script>

Appkomponent

Komponenten App (App.razor) liknar den App komponent som finns i Blazor Server appar:

På grund av ändringar i ramverket i olika versioner av ASP.NET Core visas inte Razor uppmärkning för App-komponenten (App.razor) i den här sektionen. Om du vill kontrollera komponentens markering för en viss version använder du antingen av följande metoder:

• Skapa en app som är förberedd för autentisering från standardprojektmallen Blazor WebAssembly för versionen av ASP.NET Core som du avser att använda. Granska komponenten App (App.razor) i den genererade appen.

• Granska komponenten App (App.razor) i referenskälla. Välj versionen från grenväljaren och sök efter komponenten i ProjectTemplates-mappen på lagringsplatsen eftersom den har flyttats under åren.

  Note

  Dokumentationslänkar till .NET-referenskällan läser vanligtvis in lagringsplatsens standardgren, vilket representerar den aktuella utvecklingen för nästa version av .NET. Om du vill välja en tagg för en specifik version använder du listrutan Växla grenar eller taggar. Mer information finns i Så här väljer du en versionstagg för ASP.NET Core-källkod (dotnet/AspNetCore.Docs #26205).

RedirectToLogin-komponent

Komponenten RedirectToLogin (RedirectToLogin.razor):

• Hanterar omdirigering av obehöriga användare till inloggningssidan.
• Den aktuella URL:en som användaren försöker komma åt underhålls av så att de kan returneras till den sidan om autentiseringen lyckas med:
  • tillstånd för navigeringshistorik i ASP.NET Core i .NET 7 eller senare.
  • En frågesträng i ASP.NET Core i .NET 6 eller tidigare.

Granska komponenten RedirectToLogin i referenskälla. Platsen för komponenten ändrades över tid, så använd GitHub-sökverktyg för att hitta komponenten.

Inloggningssökvägen kan anpassas av appen (RemoteAuthenticationApplicationPathsOptions.LogInPathramverksstandarder (dotnet/aspnetcore referenskälla)). Projektmallens komponent använder standardinloggningssökvägen RedirectToLoginauthentication/loginför .

Om en app anpassar inloggningssökvägen använder du någon av följande metoder:

• Matcha sökvägen i den hårdkodade strängen i komponenten RedirectToLogin .

• Mata in RemoteAuthenticationOptions för att hämta det konfigurerade värdet. Anta till exempel den här metoden när du anpassar sökvägen med AddApiAuthorization. Lägg till följande direktiv överst i komponenten RedirectToLogin :

  @using Microsoft.Extensions.Options
  @inject IOptionsSnapshot<RemoteAuthenticationOptions<ApiAuthorizationProviderOptions>> RemoteOptions
  

  Ändra komponentens omdirigering i OnInitialized -metoden:

  - Navigation.NavigateToLogin("authentication/login");
  + Navigation.NavigateToLogin(RemoteOptions.Get(Options.DefaultName)
  +     .AuthenticationPaths.LogInPath);
  

  Note

  Om andra sökvägar skiljer sig från projektmallens sökvägar eller ramverkets standardsökvägar bör de hanteras på samma sätt.

LoginDisplay-komponent

Komponenten LoginDisplay (LoginDisplay.razor) återges i komponenten MainLayout (MainLayout.razor) och hanterar följande beteenden:

• För autentiserade användare:
  • Visar det aktuella användarnamnet.
  • Erbjuder en länk till användarprofilsidan i ASP.NET Core Identity.
  • Erbjuder en knapp för att logga ut från appen.
• För anonyma användare:
  • Erbjuder möjligheten att registrera.
  • Erbjuder alternativet att logga in.

På grund av ändringar i ramverket genom utgåvor av ASP.NET Core visas inte Razor-markeringen för LoginDisplay-komponenten i det här avsnittet. Om du vill kontrollera komponentens markering för en viss version använder du antingen av följande metoder:

• Skapa en app som är förberedd för autentisering från standardprojektmallen Blazor WebAssembly för versionen av ASP.NET Core som du avser att använda. Granska LoginDisplay komponenten i den genererade appen.

• Granska komponenten LoginDisplay i referenskälla. Platsen för komponenten ändrades över tid, så använd GitHub-sökverktyg för att hitta komponenten. Mallinnehållet för Hosted lika med true används.

  Note

  Dokumentationslänkar till .NET-referenskällan läser vanligtvis in lagringsplatsens standardgren, vilket representerar den aktuella utvecklingen för nästa version av .NET. Om du vill välja en tagg för en specifik version använder du listrutan Växla grenar eller taggar. Mer information finns i Så här väljer du en versionstagg för ASP.NET Core-källkod (dotnet/AspNetCore.Docs #26205).

Autentiseringskomponent

Sidan som skapas av komponenten Authentication (Pages/Authentication.razor) definierar de vägar som krävs för att hantera olika autentiseringssteg.

Komponenten RemoteAuthenticatorView:

• Tillhandahålls av Microsoft.AspNetCore.Components.WebAssembly.Authentication paketet.
• Hanterar att utföra lämpliga åtgärder i varje fas av autentiseringen.

@page "/authentication/{action}"
@using Microsoft.AspNetCore.Components.WebAssembly.Authentication

<RemoteAuthenticatorView Action="@Action" />

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

Troubleshoot

Logging

Information om hur du aktiverar felsökning eller spårningsloggning för Blazor WebAssembly autentisering finns i avsnittet autentiseringsloggning på klientsidani ASP.NET Core-loggning Blazor med artikelversionsväljaren inställd på ASP.NET Core i .NET 7 eller senare.

Vanliga fel

• Felkonfiguration av appen eller Identity-leverantören (IP)

  De vanligaste felen orsakas av felaktig konfiguration. Följande är några exempel:

  • Beroende på kraven i scenariot förhindrar en saknad eller felaktig utfärdare, instans, klient-ID, klientdomän, klient-ID eller omdirigerings-URI en app från att autentisera klienter.
  • Felaktiga omfång för begäran hindrar klienter från att komma åt serverwebb-API-slutpunkter.
  • Felaktiga eller saknade server-API-behörigheter hindrar klienter från att komma åt serverwebb-API-slutpunkter.
  • Köra appen på en annan port än vad som har konfigurerats i omdirigerings-URI:n för IP-adressens appregistrering. Observera att en port inte krävs för Microsoft Entra-ID och en app som körs på en localhost utvecklingstestningsadress, men appens portkonfiguration och porten där appen körs måste matcha för icke-localhost adresser.

  Konfigurationsavsnitt i den här artikelns vägledning visar exempel på rätt konfiguration. Kontrollera noggrant varje avsnitt i artikeln som letar efter felkonfiguration av appar och IP-adresser.

  Om konfigurationen verkar vara korrekt:

  • Analysera applikationsloggar.

  • Granska nätverkstrafiken mellan klientappen och IP- eller serverappen med webbläsarens utvecklarverktyg. Ofta returneras ett exakt felmeddelande eller ett meddelande med en ledtråd till vad som orsakar problemet till klienten av IP- eller serverappen efter en begäran. Vägledning för utvecklarverktyg finns i följande artiklar:

    • Google Chrome (Google-dokumentation)
    • Microsoft Edge
    • Mozilla Firefox (Mozilla-dokumentation)

  • För versioner av Blazor där en JSON-webbtoken (JWT) används avkodar du innehållet i token som används för att autentisera en klient eller komma åt ett webb-API för servrar, beroende på var problemet uppstår. Mer information finns i Granska innehållet i en JSON-webbtoken (JWT).

  Dokumentationsteamet svarar på dokumentfeedback och buggar i artiklar (öppna ett problem från Den här sidan feedbackavsnittet) men kan inte tillhandahålla produktsupport. Det finns flera offentliga supportforum som hjälper dig att felsöka en app. Vi rekommenderar följande:

  • Stack Overflow (tagg: blazor)
  • ASP.NET Core Slack Team
  • Blazor Gitter

  Föregående forum ägs eller kontrolleras inte av Microsoft.

  För rapporter om icke-säkerhetsrelaterade, icke-känsliga och icke-konfidentiella reproducerbara ramverksfel, rapportera ett problem till ASP.NET Core produktgrupp. Skapa inte ett ärende med produktgruppen förrän du noggrant har undersökt orsaken till problemet och inte kan lösa det själv eller med hjälp av gemenskapen på ett offentligt supportforum. Produktenheten kan inte felsöka enskilda appar som har brutits på grund av enkel felkonfiguration eller användningsfall som rör tjänster från tredje part. Om en rapport är känslig eller konfidentiell eller beskriver en potentiell säkerhetsbrist i produkten som cyberattacker kan utnyttja kan du läsa Rapportering av säkerhetsproblem och buggar (dotnet/aspnetcore GitHub-lagringsplats).

• Obehörig klient för ME-ID

  info: Microsoft.AspNetCore.Authorization.DefaultAuthorizationService[2] Auktoriseringen misslyckades. Dessa krav uppfylldes inte: DenyAnonymousAuthorizationRequirement: Kräver en autentiserad användare.

  Återanropsfel för inloggning från ME-ID:

  • Fel: unauthorized_client
  • Beskrivning: AADB2C90058: The provided application is not configured to allow public clients.

  Så här löser du felet:

  1. Gå till -appens manifest i Azure-portalen.
  2. Ange attributet allowPublicClient till null eller true.

Cookies och webbplatsdata

Cookies och webbplatsdata kan sparas mellan appuppdateringar och störa testning och felsökning. Rensa följande när du gör ändringar i appkoden, ändringar av användarkonton med providern eller konfigurationsändringar för providerappen:

• Cookies för användarinloggning
• Appcookies
• Cachelagrade och lagrade webbplatsdata

En metod för att förhindra kvardröjande cookies och webbplatsdata från att störa testning och felsökning är att:

• Konfigurera en webbläsare
  • Använd en webbläsare för testning som du kan konfigurera för att ta bort alla cookie och platsdata varje gång webbläsaren stängs.
  • Kontrollera att webbläsaren stängs manuellt eller av IDE för ändringar i appen, testanvändaren eller providerkonfigurationen.
• Använd ett anpassat kommando för att öppna en webbläsare i InPrivate- eller Incognito-läge i Visual Studio:
  • Öppna dialogrutan Bläddra med från Visual Studios Kör-knapp.
  • Välj knappen Lägg till.
  • Ange sökvägen till webbläsaren i fältet Program. Följande exekverbara filvägar är typiska installationsplatser för Windows 10. Om webbläsaren är installerad på en annan plats eller om du inte använder Windows 10 anger du sökvägen till webbläsarens körbara fil.
    • 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
  • I fältet Argument anger du det kommandoradsalternativ som webbläsaren använder för att öppna i InPrivate- eller Inkognitoläge. Vissa webbläsare kräver appens URL.
    • Microsoft Edge: Använd -inprivate.
    • Google Chrome: Använd --incognito --new-window {URL}, där platshållaren för {URL} är url:en som ska öppnas (till exempel https://localhost:5001).
    • Mozilla Firefox: Använd -private -url {URL}, där platshållaren {URL} är url:en som ska öppnas (till exempel https://localhost:5001).
  • Ange ett namn i fältet Vänligt namn. Till exempel Firefox Auth Testing.
  • Välj knappen OK.
  • Om du vill undvika att behöva välja webbläsarprofilen för varje iteration av testning med en app anger du profilen som standard med knappen Ange som standard.
  • Kontrollera att webbläsaren är stängd av IDE för alla ändringar i appen, testanvändaren eller providerkonfigurationen.

Appuppgraderingar

En fungerande app kan misslyckas omedelbart efter att ha uppgraderat .NET SDK på utvecklingsdatorn eller ändrat paketversioner i appen. I vissa fall kan osammanhängande paket orsaka problem för en app när man utför större uppgraderingar. De flesta av dessa problem kan åtgärdas genom att följa dessa instruktioner:

1. Rensa det lokala systemets NuGet-paketcacheminnen genom att köra dotnet nuget locals all --clear från ett kommandogränssnitt.
2. Ta bort projektets mappar bin och obj.
3. Återställa och återskapa projektet.
4. Ta bort alla filer i distributionsmappen på servern innan du distribuerar om appen.

Inspektera användaren

Följande User komponent kan användas direkt i appar eller fungera som grund för ytterligare anpassning.

User.razor:

@page "/user"
@attribute [Authorize]
@using System.Text.Json
@using System.Security.Claims
@inject IAccessTokenProvider AuthorizationService

<h1>@AuthenticatedUser?.Identity?.Name</h1>

<h2>Claims</h2>

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

<h2>Access token</h2>

<p id="access-token">@AccessToken?.Value</p>

<h2>Access token claims</h2>

@foreach (var claim in GetAccessTokenClaims())
{
    <p>@(claim.Key): @claim.Value.ToString()</p>
}

@if (AccessToken != null)
{
    <h2>Access token expires</h2>

    <p>Current time: <span id="current-time">@DateTimeOffset.Now</span></p>
    <p id="access-token-expires">@AccessToken.Expires</p>

    <h2>Access token granted scopes (as reported by the API)</h2>

    @foreach (var scope in AccessToken.GrantedScopes)
    {
        <p>Scope: @scope</p>
    }
}

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

    public ClaimsPrincipal AuthenticatedUser { get; set; }
    public AccessToken AccessToken { get; set; }

    protected override async Task OnInitializedAsync()
    {
        await base.OnInitializedAsync();
        var state = await AuthenticationState;
        var accessTokenResult = await AuthorizationService.RequestAccessToken();

        if (!accessTokenResult.TryGetToken(out var token))
        {
            throw new InvalidOperationException(
                "Failed to provision the access token.");
        }

        AccessToken = token;

        AuthenticatedUser = state.User;
    }

    protected IDictionary<string, object> GetAccessTokenClaims()
    {
        if (AccessToken == null)
        {
            return new Dictionary<string, object>();
        }

        // header.payload.signature
        var payload = AccessToken.Value.Split(".")[1];
        var base64Payload = payload.Replace('-', '+').Replace('_', '/')
            .PadRight(payload.Length + (4 - payload.Length % 4) % 4, '=');

        return JsonSerializer.Deserialize<IDictionary<string, object>>(
            Convert.FromBase64String(base64Payload));
    }
}

Granska innehållet i en JSON-webbtoken (JWT)

Om du vill avkoda en JSON-webbtoken (JWT) använder du Microsofts jwt.ms-verktyg. Värden i användargränssnittet lämnar aldrig webbläsaren.

Exempelkodad JWT (förkortad för visning):

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ilg1ZVhrNHh5b2pORnVtMWtsMll0djhkbE5QNC1j ... bQdHBHGcQQRbW7Wmo6SWYG4V_bU55Ug_PW4pLPr20tTS8Ct7_uwy9DWrzCMzpD-EiwT5IjXwlGX3IXVjHIlX50IVIydBoPQtadvT7saKo1G5Jmutgq41o-dmz6-yBMKV2_nXA25Q

Exempel på JWT-avkodad av verktyget för en app som autentiserar mot Azure AAD B2C:

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "X5eXk4xyojNFum1kl2Ytv8dlNP4-c57dO6QGTVBwaNk"
}.{
  "exp": 1610059429,
  "nbf": 1610055829,
  "ver": "1.0",
  "iss": "https://mysiteb2c.b2clogin.com/11112222-bbbb-3333-cccc-4444dddd5555/v2.0/",
  "sub": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "nonce": "bbbb0000-cccc-1111-dddd-2222eeee3333",
  "iat": 1610055829,
  "auth_time": 1610055822,
  "idp": "idp.com",
  "tfp": "B2C_1_signupsignin"
}.[Signature]

Ytterligare resurser

• ASP.NET Core Blazor WebAssembly ytterligare säkerhetsscenarier
• oautentiserade eller obehöriga webb-API-begäranden i en app med en säker standardklient
• Konfigurera ASP.NET Core att fungera med proxyservrar och lastbalanserare: Innehåller vägledning om:
  • Använda vidarebefordrade huvudmellanprogram för att bevara HTTPS-schemainformation över proxyservrar och interna nätverk.
  • Ytterligare scenarier och användningsfall, inklusive manuell schemakonfiguration, begärandesökvägsändringar för korrekt routning av begäranden och vidarebefordran av begärandeschemat för Linux och icke-IIS omvända proxyservrar.