Sichern einer eigenständigen ASP.NET Core Blazor WebAssembly-App mit der Authentifizierungsbibliothek

In diesem Artikel wird erläutert, wie Sie eine eigenständige ASP.NET Core Blazor WebAssembly-App mit der Blazor WebAssembly-Authentifizierungsbibliothek schützen.

Die Blazor WebAssembly Authentifizierungsbibliothek (Authentication.js) unterstützt nur den Autorisierungscodefluss für den Prüfschlüssel für den Codeaustausch (Proof Key for Code Exchange, PKCE) über die Microsoft-Authentifizierungsbibliothek (MSAL, msal.js). Um andere Genehmigungsflüsse zu implementieren, greifen Sie auf die MSAL-Anleitungen zu, um MSAL direkt zu implementieren, aber wir unterstützen oder empfehlen die Verwendung anderer Grant-Flows als PKCE für Blazor-Apps nicht.

Befolgen Sie die Leitfäden in diesem Artikel nicht für Microsoft Entra ID (ME-ID) und Azure Active Directory B2C (AAD B2C). Weitere Informationen finden Sie unter Sichern einer eigenständigen ASP.NET Core-Blazor WebAssembly-App mit Microsoft Entra ID und Sichern einer eigenständigen ASP.NET Core-Blazor WebAssembly-App mit Azure Active Directory B2C.

Nach dem Lesen dieses Artikels finden Sie weitere Informationen zu Sicherheitsszenarien unter Zusätzliche Sicherheitsszenarios für ASP.NET Core Blazor WebAssembly.

Exemplarische Vorgehensweise

In den Unterabschnitten der exemplarischen Vorgehensweise wird Folgendes erläutert:

• Registrieren einer App
• Erstellen der Blazor-App
• Ausführen der App

Registrieren einer App

Registrieren Sie eine App bei einem OIDC-Identitätsanbieter (OpenID Connect), indem Sie die Anweisungen des Maintainers des Identitätsanbieters (Identity Provider, IP) befolgen.

Notieren Sie sich folgende Informationen:

• Autorität (z. B. https://accounts.google.com/)
• Anwendungs-ID (Client-ID) (z. B. 2...7-e...q.apps.googleusercontent.com).
• Zusätzliche IP-Konfiguration (siehe IP-Dokumentation)

Hinweis

Der IP muss OIDC verwenden. Der IP von Facebook ist beispielsweise kein OIDC-konformer Anbieter. Der Leitfaden in diesem Artikel eignet sich also nicht für den Facebook-IP. Weitere Informationen finden Sie im Artikel Schützen der Blazor WebAssembly in ASP.NET Core.

Erstellen der Blazor-App

Befolgen Sie die entsprechenden Anleitungen für die Tools Ihrer Wahl, um eine eigenständige Blazor WebAssembly-App zu erstellen, die die Microsoft.AspNetCore.Components.WebAssembly.Authentication-Bibliothek verwendet. Wenn Sie Unterstützung für die Authentifizierung hinzufügen, finden Sie im Abschnitt Bestandteile der App dieses Artikels Anleitungen zum Einrichten und Konfigurieren der App.

Visual Studio

So erstellen Sie ein neues Blazor WebAssembly-Projekt mit einem Authentifizierungsmechanismus:

Nachdem Sie die Vorlage Blazor WebAssembly-App ausgewählt haben, legen Sie den Authentifizierungstyp auf Einzelne Konten fest.

Die Auswahl Einzelne Konten verwendet das Identity-System von ASP.NET Core. Über diese Auswahl erhalten Sie Unterstützung bei der Authentifizierung, und Benutzer werden nicht in einer Datenbank gespeichert. In den folgenden Abschnitten dieses Artikels finden Sie weitere Informationen.

Visual Studio Code/.NET CLI

Erstellen Sie ein neues Blazor WebAssembly-Projekt mit einem Authentifizierungsmechanismus in einem leeren Ordner. Geben Sie den Authentifizierungsmechanismus Individual mit der Option -au|--auth an, um das Identity-System von ASP.NET Core zu nutzen. Über diese Auswahl erhalten Sie Unterstützung bei der Authentifizierung, und Benutzer werden nicht in einer Datenbank gespeichert. In den folgenden Abschnitten dieses Artikels finden Sie weitere Informationen.

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

Platzhalter	Beispiel
{PROJECT NAME}	BlazorSample

Der mit der Option -o|--output angegebene Ausgabespeicherort erstellt einen Projektordner, sofern kein solcher vorhanden ist, und wird Teil des Projektnamens.

Weitere Informationen finden Sie im Befehl dotnet new im Leitfaden für .NET Core.

Konfigurieren der App

Konfigurieren Sie die App gemäß der Anleitung des IP. Für die App sind mindestens die Konfigurationseinstellungen Local:Authority und Local:ClientId in der wwwroot/appsettings.json-Datei der App erforderlich:

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

OAuth 2.0-Beispiel für den OIDC-Anbieter Google für eine App, die auf der localhost-Adresse am Port 5001 ausgeführt wird:

{
  "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"
  }
}

Der Weiterleitungs-URI (https://localhost:5001/authentication/login-callback) ist in der Konsole für Google-APIs unter Credentials>{NAME}>Authorized redirect URIs (Anmeldeinformationen > Autorisierte Weiterleitungs-URIs) registriert. Hierbei steht {NAME} für den Clientnamen der App in der App-Liste OAuth 2.0 Client IDs (Client-IDs für OAuth 2.0) der Konsole für Google-APIs.

Hinweis

Die Angabe der Portnummer für einen localhost-Umleitungs-URI ist für einige OIDC-IPs gemäß der OAuth 2.0-Spezifikation nicht erforderlich. Einige IPs lassen zu, dass der Port im Umleitungs-URI für Loopbackadressen weggelassen wird. Andere lassen die Verwendung eines Platzhalters für die Portnummer zu (z. B. *). Weitere Informationen finden Sie in der Dokumentation des jeweiligen IP.

Ausführen der App

Verwenden Sie einen der folgenden Ansätze, um die App auszuführen:

• Visual Studio
  • Wählen Sie die Schaltfläche Ausführen.
  • Verwenden Sie im Menü Debuggen>Debuggen starten.
  • Drücken Sie F5.
• .NET CLI-Befehlsshell: Führen Sie den Befehl dotnet watch (oder dotnet run) im Ordner der App aus.

Bestandteile der App

In diesem Abschnitt wird erläutert, welche Teile einer App aus der Blazor WebAssembly-Projektvorlage generiert werden und wie die Konfiguration der App erfolgt. Es gibt in diesem Abschnitt keine speziellen Anleitungen für eine grundlegende funktionierende Anwendung, wenn Sie die App mithilfe der Anweisungen im Abschnitt Vorgehensweise erstellt haben. Die Anweisungen in diesem Abschnitt sind hilfreich, um die App mit Features zur Authentifizierung und Autorisierung von Benutzer*innen zu ergänzen. Eine alternativer Ansatz zum Aktualisieren einer App besteht darin, eine neue App anhand der Anweisungen im Abschnitt Vorgehensweise zu erstellen und die Komponenten, Klassen und Ressourcen der App in die neue App zu verschieben.

Authentifizierungspaket

Wenn eine App erstellt wird, die einzelne Benutzerkonten verwendet, erhält die App automatisch einen Paketverweis für das Microsoft.AspNetCore.Components.WebAssembly.Authentication-Paket. Das Paket stellt einige Primitive bereit, die der App beim Authentifizieren von Benutzern und beim Abrufen von Token zum Aufrufen geschützter APIs helfen.

Wenn Sie einer App eine Authentifizierung hinzufügen, fügen Sie das Paket Microsoft.AspNetCore.Components.WebAssembly.Authentication der App manuell hinzu:

Hinweis

Einen Leitfaden zum Hinzufügen von Paketen zu .NET-Apps finden Sie in Installieren und Verwalten von Paketen unter Workflow der Nutzung von Paketen (NuGet-Dokumentation). Überprüfen Sie unter NuGet.org, ob die richtige Paketversion verwendet wird.

Unterstützung für Authentifizierungsdienste

Die Unterstützung für die Authentifizierung von Benutzern mithilfe von OpenID Connect (OIDC) wird im Dienstcontainer mit der vom Paket Microsoft.AspNetCore.Components.WebAssembly.Authentication bereitgestellten AddOidcAuthentication-Erweiterungsmethode registriert.

Die AddOidcAuthentication-Methode akzeptiert einen Rückruf zum Konfigurieren der für die Authentifizierung einer App mit OIDC erforderlichen Parameter. Die für das Konfigurieren der App erforderlichen Werte können über die OIDC-kompatible IP-Adresse abgerufen werden. Rufen Sie die Werte ab, wenn Sie die App registrieren. Dies erfolgt in der Regel im entsprechenden Onlineportal.

Geben Sie für eine neue App Werte für die Platzhalter {AUTHORITY} und {CLIENT ID} in der folgenden Konfiguration ein. Stellen Sie andere Konfigurationswerte bereit, die für die Verwendung mit der IP-Adresse der App erforderlich sind. Das Beispiel ist für Google, wobei PostLogoutRedirectUri, RedirectUri und ResponseType erforderlich ist. Wenn Sie einer App eine Authentifizierung hinzufügen, fügen Sie der App manuell den folgenden Code und die Konfiguration mit Werten für die Platzhalter und weitere Konfigurationswerte hinzu.

In der Program-Datei:

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

wwwroot/appsettings.json-Konfiguration

Die Konfiguration wird durch die Datei wwwroot/appsettings.json bereitgestellt:

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

Zugriffstokenbereiche

Mit der Blazor WebAssembly-Vorlage werden automatisch Standardbereiche für openid und profile konfiguriert.

Die Blazor WebAssembly-Vorlage konfiguriert die App nicht automatisch so, dass diese ein Zugriffstoken für eine sichere API anfordert. Zum Bereitstellen eines Zugriffstokens als Teil des Anmeldeflows fügen Sie den Bereich den Standardtokenbereichen von OidcProviderOptions hinzu. Wenn Sie die Authentifizierung zu einer App hinzufügen, fügen Sie manuell den folgenden Code hinzu, und konfigurieren Sie den Bereichs-URI.

In der Program-Datei:

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

Weitere Informationen finden Sie in den folgenden Abschnitten des Artikels zu zusätzlichen Szenarios:

• Anfordern zusätzlicher Zugriffstoken
• Anfügen von Token an ausgehende Anforderungen

Imports-Datei

Der Microsoft.AspNetCore.Components.Authorization-Namespace wird in der gesamten App über die _Imports.razor-Datei verfügbar gemacht:

@using System.Net.Http
@using System.Net.Http.Json
@using Microsoft.AspNetCore.Components.Authorization
@using Microsoft.AspNetCore.Components.Forms
@using Microsoft.AspNetCore.Components.Routing
@using Microsoft.AspNetCore.Components.Web
@using Microsoft.AspNetCore.Components.Web.Virtualization
@using Microsoft.AspNetCore.Components.WebAssembly.Http
@using Microsoft.JSInterop
@using {APPLICATION ASSEMBLY}
@using {APPLICATION ASSEMBLY}.Shared

Indexseite

Die Indexseite (wwwroot/index.html) enthält ein Skript, das den AuthenticationService in JavaScript definiert. AuthenticationService behandelt die Details des OIDC-Protokolls auf niedriger Ebene. Die App ruft intern die im Skript definierten Methoden auf, um die Authentifizierungsvorgänge auszuführen.

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

App-Komponente

Die App-Komponente (App.razor) ähnelt der in den Blazor Server-Apps gefundenen App-Komponente:

• Die AuthorizeRouteView-Komponente stellt sicher, dass der aktuelle Benutzer autorisiert ist, auf eine bestimmte Seite zuzugreifen; andernfalls wird die RedirectToLogin-Komponente gerendert.
• Die RedirectToLogin-Komponente verwaltet die Umleitung nicht autorisierter Benutzer auf die Anmeldeseite.

Aufgrund von Änderungen im Framework in den verschiedenen Releases von ASP.NET Core wird in diesem Abschnitt kein Razor-Markup für die Komponente App (App.razor) angezeigt. Wenn Sie das Markup der Komponente für ein bestimmtes Release überprüfen möchten, verwenden Sie einen der folgenden Ansätze:

• Erstellen Sie eine für die Authentifizierung bereitgestellte App aus der Blazor WebAssembly-Standardprojektvorlage für die Version von ASP.NET Core, die Sie verwenden möchten. Untersuchen Sie die App-Komponente (App.razor) in der generierten App.

• Untersuchen Sie die App-Komponente (App.razor) in der Verweisquelle. Wählen Sie die Version aus der Verzweigungsselektor aus, und suchen Sie nach der Komponente im ProjectTemplates-Ordner des Repositorys, da sie im Laufe der Jahre verschoben wurde.

  Hinweis

  Dokumentationslinks zur .NET-Referenzquelle laden in der Regel den Standardbranch des Repositorys, der die aktuelle Entwicklung für das nächste Release von .NET darstellt. Um ein Tag für ein bestimmtes Release auszuwählen, wählen Sie diesen mit der Dropdownliste Switch branches or tags (Branches oder Tags wechseln) aus. Weitere Informationen finden Sie unter How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205) (Auswählen eines Versionstags von ASP.NET Core-Quellcode (dotnet/AspNetCore.Docs #26205)).

RedirectToLogin-Komponente

Die RedirectToLogin-Komponente (RedirectToLogin.razor):

• Verwaltet die Umleitung nicht autorisierter Benutzer auf die Anmeldeseite.
• Die aktuelle URL, auf die der Benutzer zuzugreifen versucht, wird beibehalten, damit er zu dieser Seite zurückkehren kann, wenn die Authentifizierung erfolgreich Folgendes verwendet:
  • Navigationsverlaufsstatus in ASP.NET Core in .NET 7 oder höher.
  • Eine Abfragezeichenfolge in ASP.NET Core in .NET 6 oder früher.

Untersuchen Sie die RedirectToLogin-Komponente in der Verweisquelle. Der Speicherort der Komponente wurde im Laufe der Zeit geändert. Verwenden Sie daher GitHub-Suchtools, um die Komponente zu finden.

Hinweis

Dokumentationslinks zur .NET-Referenzquelle laden in der Regel den Standardbranch des Repositorys, der die aktuelle Entwicklung für das nächste Release von .NET darstellt. Um ein Tag für ein bestimmtes Release auszuwählen, wählen Sie diesen mit der Dropdownliste Switch branches or tags (Branches oder Tags wechseln) aus. Weitere Informationen finden Sie unter How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205) (Auswählen eines Versionstags von ASP.NET Core-Quellcode (dotnet/AspNetCore.Docs #26205)).

LoginDisplay-Komponente

Die LoginDisplay-Komponente (LoginDisplay.razor) wird in der MainLayout-Komponente (MainLayout.razor) gerendert, und sie verwaltet die folgenden Verhaltensweisen:

• Für authentifizierte Benutzer:
  • Zeigt den aktuellen Benutzernamen an
  • Stellt einen Link zur Benutzerprofilseite in ASP.NET Core-Identity bereit
  • Bietet eine Schaltfläche zum Abmelden von der App
• Für anonyme Benutzer:
  • Bietet die Option zum Registrieren
  • Bietet die Option zur Anmeldung

Aufgrund von Änderungen im Framework in den verschiedenen Releases von ASP.NET Core wird in diesem Abschnitt kein Razor-Markup für die Komponente LoginDisplay angezeigt. Wenn Sie das Markup der Komponente für ein bestimmtes Release überprüfen möchten, verwenden Sie einen der folgenden Ansätze:

• Erstellen Sie eine für die Authentifizierung bereitgestellte App aus der Blazor WebAssembly-Standardprojektvorlage für die Version von ASP.NET Core, die Sie verwenden möchten. Überprüfen Sie die Komponente LoginDisplay in der generierten App.

• Überprüfen Sie die Komponente LoginDisplay in der Verweisquelle. Der Speicherort der Komponente wurde im Laufe der Zeit geändert. Verwenden Sie daher GitHub-Suchtools, um die Komponente zu finden. Es wird der vorlagenbasierte Inhalt für Hosted gleich true verwendet.

  Hinweis

  Dokumentationslinks zur .NET-Referenzquelle laden in der Regel den Standardbranch des Repositorys, der die aktuelle Entwicklung für das nächste Release von .NET darstellt. Um ein Tag für ein bestimmtes Release auszuwählen, wählen Sie diesen mit der Dropdownliste Switch branches or tags (Branches oder Tags wechseln) aus. Weitere Informationen finden Sie unter How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205) (Auswählen eines Versionstags von ASP.NET Core-Quellcode (dotnet/AspNetCore.Docs #26205)).

Authentication-Komponente

Die von der Komponente Authentication (Pages/Authentication.razor) erstellte Seite definiert die Routen, die für die Verarbeitung unterschiedlicher Authentifizierungsstufen erforderlich sind.

Die Komponente RemoteAuthenticatorView:

• Wird vom Paket Microsoft.AspNetCore.Components.WebAssembly.Authentication bereitgestellt.
• Verwaltet die entsprechenden Aktionen in jeder Phase der Authentifizierung.

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

<RemoteAuthenticatorView Action="@Action" />

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

Hinweis

Nullwerte zulassende Verweistypen (Nullable Reference Types, NRTs) und die statische Analyse des NULL-Zustands des .NET-Compilers wird in ASP.NET Core in .NET 6 oder höher unterstützt. Vor der Veröffentlichung von ASP.NET Core in .NET 6 wird der string-Typ ohne die NULL-Typbezeichnung (?) angezeigt.

Problembehandlung

Logging

Informationen zum Aktivieren der Debugging- oder Überwachungsprotokollierung für die Blazor WebAssembly-Authentifizierung finden Sie im Abschnitt Clientseitige Authentifizierungsprotokollierung im Artikel Blazor-Protokollierung in ASP.NET Core unter der Artikelversion ASP.NET Core 7.0 oder höher.

Häufige Fehler

• Falsche Konfiguration der App oder des Identity-Anbieters (Identity Provider, IP)

  Die häufigsten Fehler werden durch eine falsche Konfiguration verursacht. Im Folgenden finden Sie einige Beispiele:

  • In Abhängigkeit von den Anforderungen des Szenarios verhindert eine fehlende oder falsche Autorität, Instanz, Mandanten-ID, Mandantendomäne oder Client-ID oder ein fehlender oder falscher Umleitungs-URI, dass Clients von einer App authentifiziert werden.
  • Falsche Anforderungsbereiche verhindern, dass Clients auf die Web-API-Endpunkte des Servers zugreifen können.
  • Falsche oder fehlende Server-API-Berechtigungen verhindern, dass Clients auf Server-Web-API-Endpunkte zugreifen können.
  • Das Ausführen der App an einem anderen Port als dem, der im Umleitungs-URI der App-Registrierung für die IP konfiguriert ist. Beachten Sie, dass für Microsoft Entra ID und eine App, die unter einer localhost-Entwicklungstestadresse ausgeführt wird, kein Port erforderlich ist. Die Portkonfiguration der App und der Port, an dem die App ausgeführt wird, müssen bei Nicht-localhost-Adressen jedoch übereinstimmen.

  Die Konfigurationsabschnitte in den Anleitungen in diesem Artikel enthalten Beispiele für die richtige Konfiguration. Lesen Sie jeden Abschnitt des Artikels sorgfältig durch, und achten Sie auf falsche App- und IP-Konfigurationen.

  Wenn die Konfiguration anscheinend korrekt ist:

  • Analysieren Sie Anwendungsprotokolle.

  • Überprüfen Sie den Netzwerkdatenverkehr zwischen der Client-App und dem IP oder der Server-App mit den Entwicklertools des Browsers. Häufig wird vom IP oder von der Server-App eine präzise Fehlermeldung oder eine Meldung mit einem Hinweis auf die Ursache des Problems zurückgegeben, nachdem eine Anforderung erfolgt ist. Anleitungen zu den Entwicklertools finden Sie in den folgenden Artikeln:

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

  • Decodieren Sie bei Blazor-Releases, in denen ein JSON Web Token (JWT) verwendet wird, den Inhalt des Tokens, das für die Authentifizierung eines Clients oder den Zugriff auf die Web-API des Servers verwendet wird. Letzteres hängt davon ab, wo das Problem auftritt. Weitere Informationen finden Sie unter Überprüfen des Inhalts eines JSON Web Tokens (JWT).

  Das Dokumentationsteam berücksichtigt Feedback zur Dokumentation und zu Fehlern in Artikeln. (Legen Sie im Feedbackbereich auf dieser Seite ein Ticket an.) Es leistet jedoch keinen Produktsupport. Es gibt einige öffentliche Supportforen, die bei der Problembehandlung für eine App weiterhelfen. Es wird Folgendes empfohlen:

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

  Die genannten Foren werden nicht von Microsoft betrieben oder kontrolliert.

  Bei nicht sicherheitsbezogenen, nicht sensiblen und nicht vertraulichen Fehlerberichten zum Framework wird legen Sie ein Ticket für die ASP.NET Core-Produkteinheit an. Legen Sie ein Ticket für die Produkteinheit erst an, wenn Sie die Ursache eines Problems gründlich untersucht haben und es nicht selbst oder mithilfe der Community in einem öffentlichen Supportforum lösen konnten. Die Produkteinheit kann keine Problembehandlung für einzelne Apps durchführen, die aufgrund einer einfachen Fehlkonfiguration oder in Anwendungsfällen mit Drittanbieterdiensten nicht funktionieren. Wenn ein Bericht sensibler oder vertraulicher Natur ist oder eine potenzielle Sicherheitslücke im Produkt beschreibt, die von Cyberkriminellen ausgenutzt werden könnte, lesen Sie bitte lden von Sicherheitsproblemen und Fehlern (dotnet/aspnetcore GitHub Repository).

• Nicht autorisierter Client für ME-ID

  Info: Die Autorisierung von Microsoft.AspNetCore.Authorization.DefaultAuthorizationService[2] Authorization ist fehlgeschlagen. Diese Anforderungen wurden nicht erfüllt: DenyAnonymousAuthorizationRequirement: Erfordert einen authentifizierten Benutzer.

  Anmelderückruffehler von ME-ID:

  • Fehler: unauthorized_client
  • Description (Beschreibung): AADB2C90058: The provided application is not configured to allow public clients.

  So beheben Sie den Fehler

  1. Greifen Sie im Azure-Portal auf das Manifest der App zu.
  2. Legen Sie das allowPublicClient-Attribut auf null oder true fest.

Cookies und Standortdaten

Cookies und Standortdaten können über App-Updates hinweg beibehalten werden und das Testen und die Problembehandlung beeinträchtigen. Entfernen Sie Folgendes, wenn Sie Änderungen am App-Code, Änderungen an den Benutzerkonten beim Anbieter oder Konfigurationsänderungen an Anbieter-Apps vornehmen:

• Anmelde-Cookies von Benutzern
• App-Cookies
• Zwischengespeicherte und gespeicherte Standortdaten

Ein Ansatz, um zu verhindern, dass veraltete Cookies und Standortdaten das Testen und die Problembehandlung beeinträchtigen, ist folgender:

• Browser konfigurieren
  • Verwenden Sie zum Testen einen Browser, den Sie so konfigurieren können, dass alle cookies und Standortdaten jedes Mal gelöscht werden, wenn der Browser geschlossen wird.
  • Stellen Sie sicher, dass der Browser manuell oder durch die IDE für alle Änderungen an der App, dem Testbenutzer oder der Anbieterkonfiguration geschlossen wird.
• Verwenden Sie einen benutzerdefinierten Befehl, um in Visual Studio einen Browser im privaten oder Inkognito-Modus zu öffnen:
  • Öffnen Sie mithilfe der Schaltfläche Ausführen von Visual Studio das Dialogfeld Browserauswahl.
  • Wählen Sie die Schaltfläche Hinzufügen aus.
  • Geben Sie im Feld Programm den Pfad zu Ihrem Browser an. Die folgenden Pfade für ausführbare Dateien sind typische Installationspfade für Windows 10. Wenn Ihr Browser an einem anderen Speicherort installiert ist oder Sie nicht Windows 10 verwenden, geben Sie den Pfad zur ausführbaren Datei des Browsers an.
    • 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
  • Geben Sie im Feld Argumente die Befehlszeilenoption an, die der Browser verwendet, um im privaten oder Inkognito-Modus geöffnet zu werden. Für einige Browser ist die URL der App erforderlich.
    • Microsoft Edge: Verwenden Sie -inprivate.
    • Google Chrome: Verwenden Sie --incognito --new-window {URL}, wobei der Platzhalter {URL} die zu öffnende URL ist (z. B. https://localhost:5001).
    • Mozilla Firefox: Verwenden Sie -private -url {URL}, wobei der Platzhalter {URL} die zu öffnende URL ist (z. B. https://localhost:5001).
  • Geben Sie im Feld Anzeigename einen Namen ein. Beispielsweise Firefox Auth Testing.
  • Klicken Sie auf die Schaltfläche OK.
  • Um zu vermeiden, dass das Browserprofil für jede einzelne Testiteration einer App ausgewählt werden muss, legen Sie das Profil mithilfe der Schaltfläche Als Standard festlegen als Standard fest.
  • Stellen Sie sicher, dass der Browser von der IDE für alle Änderungen an der App, dem Testbenutzer oder der Anbieterkonfiguration geschlossen wird.

App-Upgrades

Eine funktionsfähige App kann direkt nach der Durchführung eines Upgrades für das .NET Core SDK auf dem Entwicklungscomputer oder einer Änderung der Paketversionen in der App fehlschlagen. In einigen Fällen können inkohärente Pakete eine App beschädigen, wenn größere Upgrades durchgeführt werden. Die meisten dieser Probleme können durch Befolgung der folgenden Anweisungen behoben werden:

1. Löschen Sie die Caches für NuGet-Pakete auf dem lokalen System, indem Sie dotnet nuget locals all --clear in einer Befehlsshell ausführen.
2. Löschen Sie die Ordner bin und obj des Projekts.
3. Stellen Sie das Projekt wieder her und erstellen Sie es neu.
4. Löschen Sie alle Dateien im Bereitstellungsordner auf dem Server, bevor Sie die App noch mal bereitstellen.

Hinweis

Die Verwendung von Paketversionen, die mit dem Zielframework der App nicht kompatibel sind, wird nicht unterstützt. Informationen zu einem Paket finden Sie mithilfe der NuGet Gallery oder des FuGet Package Explorer.

Überprüfen des Benutzers

Die folgende User-Komponente kann direkt in Anwendungen verwendet werden oder als Grundlage für weitere Anpassungen dienen.

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

Überprüfen des Inhalts eines JSON Web Tokens (JWT)

Verwenden Sie zum Decodieren eines JSON Web Tokens (JWT) das Tool jwt.ms von Microsoft. Werte in der Benutzeroberfläche verlassen nie Ihren Browser.

Beispiel für ein codiertes JWT (für die Darstellung gekürzt):

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ilg1ZVhrNHh5b2pORnVtMWtsMll0djhkbE5QNC1j ... bQdHBHGcQQRbW7Wmo6SWYG4V_bU55Ug_PW4pLPr20tTS8Ct7_uwy9DWrzCMzpD-EiwT5IjXwlGX3IXVjHIlX50IVIydBoPQtadvT7saKo1G5Jmutgq41o-dmz6-yBMKV2_nXA25Q

Beispiel-JWT, das mit dem Tool für eine App decodiert wurde, das bei Azure AAD B2C authentifiziert wird:

{
  "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]

Zusätzliche Ressourcen

• Zusätzliche Sicherheitsszenarios für Blazor WebAssembly in ASP.NET Core
• Nicht authentifizierte oder nicht autorisierte Web-API-Anforderungen in einer App mit einem sicheren Standardclient
• Konfigurieren von ASP.NET Core zur Verwendung mit Proxyservern und Lastenausgleich: Umfasst Hinweise zu:
  • der Verwendung der Middleware für weitergeleitete Header, um HTTPS-Schemainformationen für Proxyserver und interne Netzwerke zu schützen
  • zusätzlichen Szenarios und Anwendungsfällen, einschließlich der manuellen Schemakonfiguration, Änderungen von Anforderungspfaden für fehlerfreies Routing von Anforderungen und der Weiterleitung des Anforderungsschemas für Linux- und Nicht-IIS-Reverseproxys.