Freigeben über

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

Note

Dies ist nicht die neueste Version dieses Artikels. Die aktuelle Version finden Sie in der .NET 10-Version dieses Artikels.

Warning

Diese Version von ASP.NET Core wird nicht mehr unterstützt. Weitere Informationen finden Sie in der .NET- und .NET Core-Supportrichtlinie. Die aktuelle Version finden Sie in der .NET 9-Version dieses Artikels.

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.

Walkthrough

In den Unterabschnitten der Schritt-für-Schritt-Anleitung wird Folgendes erläutert:

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

Registrieren einer App

Registrieren Sie eine App bei einem OIDCIdentity-Identitätsanbieter (OpenID Connect), indem Sie die Anweisungen des Maintainers des Identitätsanbieters (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)

Note

Der IP muss OIDC verwenden. Die IP von Facebook ist beispielsweise kein OIDC-konformer Anbieter, daher funktioniert die Anleitung in diesem Thema nicht mit der 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.

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.

Nachdem Sie die Vorlage Blazor WebAssembly-App ausgewählt haben, legen Sie den Authentifizierungstyp auf Einzelne Konten fest. Stellen Sie sicher, dass die Checkbox Von ASP.NET Core gehostet nicht markiert ist.

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.

Konfigurieren der App

Konfigurieren Sie die App gemäß den Anweisungen des IP (Internetprotokolls). 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 OIDC-Beispiel für Google für eine App, die unter der Adresse localhost auf Port 5001 läuft:

{
  "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 Google APIs-Konsole unter Anmeldeinformationen>{NAME}>Autorisierte Weiterleitungs-URIs registriert, wobei {NAME} für den Clientnamen der App in der App-Liste OAuth 2.0 Client-IDs der Google APIs-Konsole steht.

Note

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 für die Verwendung einzelner Konten erstellt wird, empfängt 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:

Note

Eine Anleitung zum Hinzufügen von Paketen zu .NET-Anwendungen finden Sie in den Artikeln unter Pakete installieren und verwalten unter Workflow für die Paketnutzung (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 AddOidcAuthentication bereitgestellten Microsoft.AspNetCore.Components.WebAssembly.Authentication-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:

Importiert die Datei

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

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

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 App-Apps gefundenen Blazor Server-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.
  • Die CascadingAuthenticationState-Komponente verwaltet das Verfügbarmachen der AuthenticationState-Komponente für die restliche App.
  • 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.

    Note

    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.

Der Anmeldepfad kann von der App angepasst werden (RemoteAuthenticationApplicationPathsOptions.LogInPathFrameworkstandardwerte (dotnet/aspnetcore Referenzquelle). Die Komponente der RedirectToLogin Projektvorlage verwendet den Standard-Anmeldepfad von authentication/login.

Note

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

Wenn eine App den Anmeldepfad anpasst, führen Sie eine der folgenden Ansätze aus:

  • Stimmen Sie den Pfad in der hartcodierten Zeichenfolge in der RedirectToLogin Komponente überein.

  • Injizieren RemoteAuthenticationOptions , um den konfigurierten Wert abzurufen. Nehmen Sie diesen Ansatz z. B. beim Anpassen des Pfads mit AddApiAuthorization. Fügen Sie oben in der RedirectToLogin Komponente die folgenden Direktiven hinzu:

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

    Ändern Sie die Umleitung der Komponente in der OnInitialized Methode:

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

    Note

    Wenn andere Pfade von den Pfaden der Projektvorlage oder den Standardpfaden des Frameworks abweichen, sollten sie auf die gleiche Weise verwaltet werden.

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.

  • Untersuchen Sie die LoginDisplay-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. Es wird der vorlagenbasierte Inhalt für Hosted gleich true verwendet.

    Note

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

Authentifizierungskomponente

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:

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

<RemoteAuthenticatorView Action="@Action" />

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

Note

Nullwerte zulassende Verweistypen (Nullable Reference Types, NRTs) und die statische Analyse des NULL-Zustands des .NET-Compilers werden 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.

Troubleshoot

Logging

Informationen zum Aktivieren der Debug- oder Ablaufverfolgungsprotokollierung für Blazor WebAssembly die Authentifizierung finden Sie im Abschnitt zur clientseitigen AuthentifizierungsprotokollierungASP.NET Core-ProtokollierungBlazor, wobei die Artikelversionsauswahl auf ASP.NET Core in .NET 7 oder höher festgelegt ist.

Häufige Fehler

  • Fehlkonfiguration der App oder des Identity-Providers (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 von der IP-Adresse oder der Serveranwendung eine präzise Fehlermeldung oder ein Hinweis auf die Ursache des Problems zurückgegeben, nachdem eine Anfrage gestellt wurde. Anleitungen zu den Entwicklertools finden Sie in den folgenden Artikeln:

    • 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:

    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 Melden 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 funktionierende App kann unmittelbar nach dem Upgrade des .NET SDK auf dem Entwicklungscomputer oder beim Ändern von Paketversionen innerhalb 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.

Note

Die Verwendung von Paketversionen, die mit dem Zielframework der App nicht kompatibel sind, wird nicht unterstützt. Um Informationen zu einem Paket zu erhalten, verwenden Sie die NuGet Gallery.

Ausführen der Server-App

Stellen Sie beim Testen und Beheben von Problemen bei einer gehosteten Blazor WebAssembly-Lösung sicher, dass Sie die App aus dem Server-Projekt ausführen.

Ü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 dekodiert wurde, die 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]

Weitere Ressourcen

  • Last updated on