Sichern einer ASP.NET Core gehosteten Blazor WebAssembly-App mit Microsoft Entera ID

  • Artikel

In diesem Artikel wird erläutert, wie Sie eine gehostete Blazor WebAssembly-Lösung erstellen, die Microsoft Entra ID (ME-ID) für die Authentifizierung verwendet. Dieser Artikel befasst sich mit einer Einzelmandanten-App mit einer Azure-App-Registrierung in einem einzelnen Mandanten.

In diesem Artikel wird keine ME-ID-Registrierung mit mehreren Mandanten behandelt. Weitere Informationen finden Sie unter Hinzufügen der Mehrinstanzenfähigkeit zu Ihrer Anwendung.

Dieser Artikel konzentriert sich auf die Verwendung eines Microsoft Entra-Mandanten wie unter Schnellstart: Einrichten eines Mandanten beschrieben. Wenn die App in einem Azure Active Directory B2C-Mandanten registriert ist, wie im Tutorial: Erstellen eines Azure Active Directory B2C-Mandanten beschrieben wird, jedoch dem Leitfaden dieses Artikels folgt, wird der App-ID-URI von ME-ID anders verwaltet. Weitere Informationen finden Sie im Abschnitt Verwenden eines Azure Active Directory B2C-Mandanten in diesem Artikel.

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:

  • Erstellen eines Mandanten in Azure
  • Registrieren einer Server-API-App in Azure
  • Registrieren einer Client-App in Azure
  • Erstellen der Blazor-App
  • Ändern der appsettings.json-Konfiguration für den Server
  • Ändern des Standardschemas für den Zugriffstokenbereich
  • Ausführen der App

Erstellen eines Mandanten in Azure

Befolgen Sie den Leitfaden unter Schnellstart: Einrichten eines Mandanten, um einen Mandanten in ME-ID zu erstellen.

Registrieren einer Server-API-App in Azure

Registrieren einer ME-ID-App für die Server-API-App:

  1. Navigieren Sie im Azure-Portal zu Microsoft Entra-ID. Wählen Sie auf der Seitenleiste Anwendungen> App-Registrierungen aus. Klicken Sie auf die Schaltfläche Neue Registrierung.
  2. Geben Sie einen Namen für die App an (z. B. Blazor Server ME-ID).
  3. Wählen Sie einen Unterstützten Kontotyp aus. Hier können Sie die Option Nur Konten in diesem Organisationsverzeichnis (einzelner Mandant) auswählen.
  4. Die Server-API-App erfordert in diesem Szenario keinen Umleitungs-URI. Treffen Sie in der Dropdownliste Plattform auswählen keine Auswahl, und geben Sie keinen Umleitungs-URI ein.
  5. In diesem Artikel wird davon ausgegangen, dass die App in einem Microsoft Entra-Mandanten registriert ist. Wenn die App in einem Azure Active Directory B2C-Mandanten registriert ist, ist das Kontrollkästchen Berechtigungen>Administratoreinwilligung für openid und offline_access erteilen vorhanden und aktiviert. Deaktivieren Sie das Kontrollkästchen, um die Einstellung zu deaktivieren. Wenn Sie einen Active Azure Directory-Mandanten verwenden, ist das Kontrollkästchen nicht vorhanden.
  6. Wählen Sie Registrieren.

Notieren Sie sich folgende Informationen:

  • Anwendungs-ID (Client-ID) der Server-API-App (z. B. 41451fa7-82d9-4673-8fa5-69eff5a761fd)
  • Verzeichnis-ID (Mandanten-ID) (z. B. e86c78e2-8bb4-4c41-aefd-918e0565a45e)
  • Primäre Domäne, Herausgeberdomäne oder Mandantendomäne für ME-ID (z. B. contoso.onmicrosoft.com): Die Domäne ist für die registrierte App als Herausgeberdomäne auf dem Blatt Branding im Azure-Portal verfügbar.

Entfernen Sie in API-Berechtigungen die Berechtigung Microsoft Graph>User.Read, da für die Server-API-App kein zusätzlicher API-Zugriff erforderlich ist, nur um Benutzer anzumelden und Server-API-Endpunkte aufzurufen.

Gehen Sie unter Eine API verfügbar machen wie folgt vor:

  1. Bestätigen Sie den App-ID-URI im Format api://{SERVER API APP CLIENT ID}, oder fügen Sie ihn hinzu.
  2. Wählen Sie Bereich hinzufügen.
  3. Wählen Sie Speichern und fortfahren aus.
  4. Geben Sie einen Bereichsnamen an (z. B. API.Access).
  5. Geben Sie einen Anzeigenamen der Administratorzustimmung an (z. B. Access API).
  6. Geben Sie eine Beschreibung der Administratorzustimmung an (z. B. Allows the app to access server app API endpoints.).
  7. Vergewissern Sie sich, dass Zustand auf Aktiviert gesetzt ist.
  8. Wählen Sie Bereich hinzufügen aus.

Notieren Sie sich folgende Informationen:

  • Die GUID des App-ID-URI (z. B. Datensatz 41451fa7-82d9-4673-8fa5-69eff5a761fd aus dem App-ID-URI von api://41451fa7-82d9-4673-8fa5-69eff5a761fd)
  • Bereichsname (beispielsweise API.Access)

Wichtig

Wenn ein benutzerdefinierter Wert für den App-ID-URI verwendet wird, sind Konfigurationsänderungen sowohl für die App Server als auch Client erforderlich, nachdem die Apps aus der Blazor WebAssembly-Projektvorlage erstellt wurden. Weitere Informationen finden Sie im Abschnitt Verwenden eines benutzerdefinierten App-ID-URI.

Registrieren einer Client-App in Azure

Registrieren einer ME-ID-App für die Client-App:

  1. Navigieren Sie im Azure-Portal zu Microsoft Entra ID. Wählen Sie auf der Seitenleiste App-Registrierungen aus. Klicken Sie auf die Schaltfläche Neue Registrierung.
  2. Geben Sie einen Namen für die App an (z. B. Blazor Client ME-ID).
  3. Wählen Sie einen Unterstützten Kontotyp aus. Hier können Sie die Option Nur Konten in diesem Organisationsverzeichnis (einzelner Mandant) auswählen.
  4. Legen Sie in der Dropdownliste Umleitungs-URI die Option Single-Page-Webanwendung (SPA) fest, und geben Sie den folgenden Umleitungs-URI an: https://localhost/authentication/login-callback. Wenn Sie den Produktionsumleitungs-URI für den Azure-Standardhost (z. B. azurewebsites.net) oder den benutzerdefinierten Domänenhost (z. B. contoso.com) kennen, können Sie den Produktionsumleitungs-URI gleichzeitig mit dem Umleitungs-URI für localhost hinzufügen. Achten Sie darauf, die Portnummer für andere Ports als :443 in alle von Ihnen hinzugefügten Produktionsumleitungs-URIs einzuschließen.
  5. In diesem Artikel wird davon ausgegangen, dass die App in einem Microsoft Entra-Mandanten registriert ist. Wenn die App in einem Azure Active Directory B2C-Mandanten registriert ist, ist das Kontrollkästchen Berechtigungen>Administratoreinwilligung für openid und offline_access erteilen vorhanden und aktiviert. Deaktivieren Sie das Kontrollkästchen, um die Einstellung zu deaktivieren. Wenn Sie einen Active Azure Directory-Mandanten verwenden, ist das Kontrollkästchen nicht vorhanden.
  6. Wählen Sie Registrieren.

Hinweis

Die Angabe der Portnummer für eine localhost-ME-ID Redirect URI ist nicht erforderlich. Weitere Informationen finden Sie unter Einschränkungen und Beschränkungen der Redirect URI (Antwort-URL): Localhost-Ausnahmen (Entra-Dokumentation).

Notieren Sie sich die Anwendungs-ID (Client-ID) der Client -App (z. B. 4369008b-21fa-427c-abaa-9b53bf58e538).

Unter Authentifizierung>Plattformkonfigurationen>Single-Page-Webanwendung:

  1. Vergewissern Sie sich, dass der Umleitungs-URI von https://localhost/authentication/login-callback vorhanden ist.
  2. Stellen Sie sicher, dass im Abschnitt Implizite Gewährung die Kontrollkästchen Zugriffstoken und ID-Token nicht aktiviert sind. Die implizite Gewährung wird für Blazor-Apps mit MSAL v2.0 oder höher nicht empfohlen. Weitere Informationen finden Sie im Artikel Schützen der Blazor WebAssembly in ASP.NET Core.
  3. Die verbleibenden Standardwerte für die App müssen für dieses Szenario nicht angepasst werden.
  4. Wählen Sie die Schaltfläche Speichern aus, wenn Sie Änderungen vorgenommen haben.

Gehen Sie unter API-Berechtigungen wie folgt vor:

  1. Sorgen Sie dafür, dass die App über die Berechtigung Microsoft Graph>User.Read verfügt.
  2. Klicken Sie auf Berechtigung hinzufügen und dann auf Meine APIs.
  3. Wählen Sie die Server-API-App aus der Spalte Name aus (z. B. Blazor Server ME-ID).
  4. Öffnen Sie die API-Liste.
  5. Ermöglichen Sie den Zugriff auf die API (z. B. API.Access).
  6. Wählen Sie Berechtigungen hinzufügen aus.
  7. Klicken Sie auf die Schaltfläche Administratoreinwilligung für {MANDANTENNAME} erteilen. Klicken Sie auf Ja, um zu bestätigen.

Wichtig

Wenn Sie im letzten Konfigurationsschritt der API-Berechtigungen nicht berechtigt sind, dem Mandanten die Administratoreinwilligung zu erteilen, da die Zustimmung zur Verwendung der App an Benutzer*innen delegiert wird, müssen Sie die folgenden zusätzlichen Schritte ausführen:

  • Die App muss eine vertrauenswürdige Herausgeberdomäne verwenden.
  • Wählen Sie in der Konfiguration der Server-App im Azure-Portal Eine API verfügbar machen aus. Wählen Sie unter Autorisierte Clientanwendungen die Schaltfläche Eine Clientanwendung hinzufügen aus. Fügen Sie die Anwendungs-ID (Client-ID) der Client-App (z. B. 4369008b-21fa-427c-abaa-9b53bf58e538) hinzu.

Erstellen der Blazor-App

Verwenden Sie einen leeren Ordner, ersetzen Sie im folgenden Befehl die Platzhalter durch die zuvor notierten Informationen, und führen Sie den Befehl in einer Befehlsshell aus:

dotnet new blazorwasm -au SingleOrg --api-client-id "{SERVER API APP CLIENT ID}" --app-id-uri "{SERVER API APP ID URI GUID}" --client-id "{CLIENT APP CLIENT ID}" --default-scope "{DEFAULT SCOPE}" --domain "{TENANT DOMAIN}" -ho -o {PROJECT NAME} --tenant-id "{TENANT ID}"

Warnung

Verwenden Sie keine Bindestriche (-) im App-Namen ({PROJECT NAME}), da die Formatierung des OIDC-App-Bezeichners dadurch beeinträchtigt wird. Die Logik in der Blazor WebAssembly-Projektvorlage verwendet den Projektnamen für einen OIDC-App-Bezeichner in der Projektmappenkonfiguration. Die Pascal-Schreibweise (BlazorSample) oder Unterstriche (Blazor_Sample) stellen akzeptable Alternativen dar. Weitere Informationen finden Sie unter Bindestriche in gehostetem Blazor WebAssembly-Projektnamen beeinträchtigen OIDC-Sicherheit (dotnet/aspnetcore 35337).

Platzhalter Name im Azure-Portal Beispiel
{PROJECT NAME} — BlazorSample
{CLIENT APP CLIENT ID} Anwendungs-ID (Client-ID) für die Client -App 4369008b-21fa-427c-abaa-9b53bf58e538
{DEFAULT SCOPE} Bereichsname API.Access
{SERVER API APP CLIENT ID} Anwendungs-ID (Client-ID) für die Server-API-App 41451fa7-82d9-4673-8fa5-69eff5a761fd
{SERVER API APP ID URI GUID} GUID des Anwendungs-ID-URI 41451fa7-82d9-4673-8fa5-69eff5a761fd (NUR GUID entspricht standardmäßig der {SERVER API APP CLIENT ID})
{TENANT DOMAIN} Primäre, Herausgeber- oder Mandantendomäne contoso.onmicrosoft.com
{TENANT ID} Verzeichnis-ID (Mandant) e86c78e2-8bb4-4c41-aefd-918e0565a45e

Der mit der Option -o|--output angegebene Ausgabespeicherort erstellt einen Projektordner, sofern kein solcher vorhanden ist, und wird Teil des Projektnamens. Verwenden Sie keine Bindestriche (-) im App-Namen, da die Formatierung des OIDC-App-Bezeichners dadurch beeinträchtigt wird (vgl. vorherige Warnung).

Wichtig

Wenn ein benutzerdefinierter Wert für den App-ID-URI verwendet wird, sind Konfigurationsänderungen sowohl für die App Server als auch Client erforderlich, nachdem die Apps aus der Blazor WebAssembly-Projektvorlage erstellt wurden. Weitere Informationen finden Sie im Abschnitt Verwenden eines benutzerdefinierten App-ID-URI.

Ausführen der App

Führen Sie die App aus dem Projekt Server heraus aus. Wenn Sie Visual Studio verwenden, haben Sie folgende beiden Möglichkeiten:

  • Wählen Sie den Dropdownpfeil neben der Schaltfläche Ausführen aus. Öffnen Sie in der Dropdownliste Startprojekte konfigurieren. Wählen Sie die Option Einzelnes Startprojekt aus. Bestätigen oder ändern Sie das Projekt für das Startprojekt in Server-Projekt.

  • Vergewissern Sie sich, dass das Projekt Server im Projektmappen-Explorer hervorgehoben ist, bevor Sie die App mit einem der folgenden Ansätze starten:

    • Wählen Sie die Schaltfläche Ausführen.
    • Verwenden Sie im Menü Debuggen>Debuggen starten.
    • Drücken Sie F5.

  • Navigieren Sie in einer Befehlsshell zum Projektordner Server der Projektmappe. Führen Sie den dotnet run-Befehl aus.

Konfigurieren von User.Identity.Name

Der Leitfaden in diesem Abschnitt umfasst optional das Auffüllen von User.Identity.Name mit dem Wert aus dem name-Anspruch.

Standardmäßig füllt die Server -App-API User.Identity.Name mit dem Wert aus dem http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name-Anspruchstyp (z. B. 2d64b3da-d9d5-42c6-9352-53d8df33d770@contoso.onmicrosoft.com) auf.

So konfigurieren Sie die App, um den Wert vom name-Anspruchstyp zu empfangen:

Bestandteile der Lösung

In diesem Abschnitt wird erläutert, welche Teile einer Projektmappe aus der Blazor WebAssembly-Projektvorlage generiert werden und wie die Client- und Server-Projekte der Projektmappe konfiguriert werden. 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.

appsettings.json-Konfiguration

Dieser Abschnitt bezieht sich auf die Server -App der Lösung.

Die Datei appsettings.json enthält die Optionen zum Konfigurieren des JWT-Bearerhandlers, der zum Überprüfen von Zugriffstoken verwendet wird. Fügen Sie den folgenden AzureAd-Konfigurationsabschnitt hinzu:

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "Domain": "{TENANT DOMAIN}",
    "TenantId": "{TENANT ID}",
    "ClientId": "{SERVER API APP CLIENT ID}",
    "CallbackPath": "/signin-oidc",
    "Scopes": "{SCOPES}"
  }
}

Beispiel:

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "Domain": "contoso.onmicrosoft.com",
    "TenantId": "e86c78e2-8bb4-4c41-aefd-918e0565a45e",
    "ClientId": "41451fa7-82d9-4673-8fa5-69eff5a761fd",
    "CallbackPath": "/signin-oidc",
    "Scopes": "API.Access"
  }
}

Wichtig

Wenn die Server-App für die Verwendung eines benutzerdefinierten App-ID-URI in ME-ID (nicht im Standardformat api://{SERVER API APP CLIENT ID}) registriert ist, lesen Sie den Abschnitt Verwenden eines benutzerdefinierten App-ID-URI. Änderungen sind sowohl den Server- als auch den Client-Apps erforderlich.

Authentifizierungspaket

Dieser Abschnitt bezieht sich auf die Server -App der Lösung.

Die Unterstützung für die Authentifizierung und Autorisierung von Aufrufen von ASP.NET Core-Web-APIs mit der Microsoft Identity Platform wird vom Paket Microsoft.Identity.Web bereitgestellt.

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.

Die Server -App einer gehosteten Blazor-Lösung, die aus der Vorlage Blazor WebAssembly erstellt wurde, enthält standardmäßig das Microsoft.Identity.Web.UI-Paket. Das Paket fügt eine Benutzeroberfläche für die Benutzerauthentifizierung in Web-Apps hinzu und wird vom Blazor-Framework nicht verwendet. Wenn die Server-App nicht verwendet wird, um Benutzer*innen direkt zu authentifizieren, kann der Paketverweis problemlos aus der Projektdatei der Server-App entfernt werden.

Unterstützung für Authentifizierungsdienste

Dieser Abschnitt bezieht sich auf die Server -App der Lösung.

Die AddAuthentication-Methode richtet Authentifizierungsdienste innerhalb der App ein und konfiguriert den JWT-Bearerhandler als Standardauthentifizierungsmethode. Mit der AddMicrosoftIdentityWebApi-Methode werden Dienste konfiguriert, um die Web-API mit Microsoft Identity Platform v 2.0 zu schützen. Diese Methode erwartet einen AzureAd-Abschnitt in der App-Konfiguration mit den erforderlichen Einstellungen zum Initialisieren der Authentifizierungsoptionen.

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApi(Configuration.GetSection("AzureAd"));

Hinweis

Wenn ein einzelnes Authentifizierungsschema registriert ist, wird es automatisch als Standardschema der App verwendet, und es ist nicht erforderlich, das Schema auf AddAuthentication oder über AuthenticationOptions anzugeben. Weitere Informationen finden Sie in der Übersicht über die ASP.NET Core- Authentifizierung und in der ASP.NET Core-Ankündigung (aspnet/Announcements #490).

UseAuthentication und UseAuthorization stellen Folgendes sicher:

  • Die App versucht, Token auf eingehende Anforderungen zu analysieren und zu überprüfen.
  • Jede Anforderung, die versucht, ohne die richtigen Anmeldeinformationen auf eine geschützte Ressource zuzugreifen, schlägt fehl.
app.UseAuthentication();
app.UseAuthorization();

WeatherForecast-Controller

Dieser Abschnitt bezieht sich auf die Server -App der Lösung.

Der WeatherForecast-Controller (Controllers/WeatherForecastController.cs) macht eine geschützte API mit dem [Authorize]-Attribut verfügbar, das auf den Controller angewandt wird. Es ist wichtig, Folgendes zu verstehen:

  • Das [Authorize]-Attribut in diesem API-Controller ist die einzige Möglichkeit, diese API vor nicht autorisiertem Zugriff zu schützen.
  • Das in der Blazor WebAssembly-App verwendete [Authorize]-Attribut dient nur als Hinweis für die App, dass der Benutzer autorisiert sein sollte, damit die App richtig funktioniert.
[Authorize]
[ApiController]
[Route("[controller]")]
[RequiredScope(RequiredScopesConfigurationKey = "AzureAd:Scopes")]
public class WeatherForecastController : ControllerBase
{
    [HttpGet]
    public IEnumerable<WeatherForecast> Get()
    {
        ...
    }
}

wwwroot/appsettings.json-Konfiguration

Dieser Abschnitt bezieht sich auf die Client -App der Lösung.

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

{
  "AzureAd": {
    "Authority": "https://login.microsoftonline.com/{TENANT ID}",
    "ClientId": "{CLIENT APP CLIENT ID}",
    "ValidateAuthority": true
  }
}

Beispiel:

{
  "AzureAd": {
    "Authority": "https://login.microsoftonline.com/e86c78e2-...-918e0565a45e",
    "ClientId": "4369008b-21fa-427c-abaa-9b53bf58e538",
    "ValidateAuthority": true
  }
}

Authentifizierungspaket

Dieser Abschnitt bezieht sich auf die Client -App der Lösung.

Wenn eine App zum Verwenden von Geschäfts-, Schul- oder Unikonten (SingleOrg) erstellt wird, erhält die App automatisch einen Paketverweis für die Authentifizierungsbibliothek von Microsoft (Microsoft.Authentication.WebAssembly.Msal). 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.Authentication.WebAssembly.Msal 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.

Das Microsoft.Authentication.WebAssembly.Msal-Paket fügt der App das Microsoft.AspNetCore.Components.WebAssembly.Authentication-Paket transitiv hinzu.

Unterstützung für Authentifizierungsdienste

Dieser Abschnitt bezieht sich auf die Client -App der Lösung.

Es wird Unterstützung für HttpClient-Instanzen hinzugefügt, die bei Anforderungen an die Server-App Zugriffstoken einschließen.

In der Program-Datei:

builder.Services.AddHttpClient("{PROJECT NAME}.ServerAPI", client => 
        client.BaseAddress = new Uri(builder.HostEnvironment.BaseAddress))
    .AddHttpMessageHandler<BaseAddressAuthorizationMessageHandler>();

builder.Services.AddScoped(sp => sp.GetRequiredService<IHttpClientFactory>()
    .CreateClient("{PROJECT NAME}.ServerAPI"));

Der Platzhalter {PROJECT NAME} ist der Projektname bei der Projektmappenerstellung. Wenn Sie z. B. einen Projektnamen von BlazorSample angeben, wird ein benannter HttpClient von BlazorSample.ServerAPI erzeugt.

Die Unterstützung für die Authentifizierung von Benutzern wird im Dienstcontainer mit der vom Paket Microsoft.Authentication.WebAssembly.Msal bereitgestellten AddMsalAuthentication-Erweiterungsmethode registriert. Diese Methode richtet die Dienste ein, die erforderlich sind, damit die App mit dem Identitätsanbieter interagiert.

In der Program-Datei:

builder.Services.AddMsalAuthentication(options =>
{
    builder.Configuration.Bind("AzureAd", options.ProviderOptions.Authentication);
    options.ProviderOptions.DefaultAccessTokenScopes.Add("{SCOPE URI}");
});

Die AddMsalAuthentication-Methode akzeptiert einen Rückruf zum Konfigurieren der für die Authentifizierung der App erforderlichen Parameter. Die zum Konfigurieren der App erforderlichen Werte können von der ME-ID-Konfiguration im Azure-Portal beim Registrieren der App abgerufen werden.

Zugriffstokenbereiche

Dieser Abschnitt bezieht sich auf die Client -App der Lösung.

Zu den Standard-Zugriffstokenbereichen zählen die Zugriffstokenbereiche, auf die Folgendes zutrifft:

  • standardmäßig in der Anmeldeanforderung enthalten
  • zum Bereitstellen eines Zugriffstokens direkt nach der Authentifizierung verwendet

Zusätzliche Bereiche können nach Bedarf in der Program-Datei hinzugefügt werden:

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

Geben Sie zusätzliche Bereiche mit AdditionalScopesToConsent an:

options.ProviderOptions.AdditionalScopesToConsent.Add("{ADDITIONAL SCOPE URI}");

Hinweis

AdditionalScopesToConsent ist nicht in der Lage, über die Zustimmungsoberfläche von Microsoft Entra ID delegierte Benutzerberechtigungen für Microsoft Graph bereitzustellen, wenn ein Benutzer zum ersten Mal eine App verwendet, die in Microsoft Azure registriert ist. Weitere Informationen finden Sie unter Verwenden der Graph-API mit ASP.NET CoreBlazor WebAssembly.

Beispiel für den Standardzugriffstokenbereich:

options.ProviderOptions.DefaultAccessTokenScopes.Add(
    "api://41451fa7-82d9-4673-8fa5-69eff5a761fd/API.Access");

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

Anmeldemodus

Dieser Abschnitt bezieht sich auf die Client -App der Lösung.

Das Framework ist standardmäßig auf den Popup-Anmeldemodus festgelegt und greift auf den Umleitungsanmeldemodus zurück, wenn kein Popup geöffnet werden kann. Konfigurieren Sie MSAL, um den Umleitungsanmeldemodus zu verwenden, indem Sie die LoginMode-Eigenschaft von MsalProviderOptions auf redirect festlegen:

builder.Services.AddMsalAuthentication(options =>
{
    ...
    options.ProviderOptions.LoginMode = "redirect";
});

Die Standardeinstellung ist popup, und der Zeichenfolgenwert berücksichtigt keine Groß-/Kleinschreibung.

Imports-Datei

Dieser Abschnitt bezieht sich auf die Client -App der Lösung.

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

Dieser Abschnitt bezieht sich auf die Client -App der Lösung.

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.Authentication.WebAssembly.Msal/AuthenticationService.js"></script>

App-Komponente

Dieser Abschnitt bezieht sich auf die Client -App der Lösung.

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

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

    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

Dieser Abschnitt bezieht sich auf die Client -App der Lösung.

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

Dieser Abschnitt bezieht sich auf die Client -App der Lösung.

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

Dieser Abschnitt bezieht sich auf die Client -App der Lösung.

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

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.

FetchData-Komponente

Dieser Abschnitt bezieht sich auf die Client -App der Lösung.

Die FetchData-Komponente zeigt Folgendes:

  • Stellen Sie ein Zugriffstoken bereit.
  • Verwenden Sie das Zugriffstoken zum Aufrufen einer geschützten Ressourcen-API in der Server-App.

Die @attribute [Authorize]-Anweisung zeigt dem Blazor WebAssembly-Autorisierungssystem an, dass der Benutzer autorisiert werden muss, um diese Komponente anzuzeigen. Das Vorhandensein des Attributs in der Client-App verhindert nicht, dass die API auf dem Server ohne die richtigen Anmeldeinformationen aufgerufen wird. Die Server-App muss auch [Authorize] auf den entsprechenden Endpunkten verwenden, um sie ordnungsgemäß zu schützen.

IAccessTokenProvider.RequestAccessToken übernimmt die Anforderung eines Zugriffstokens, das der Anforderung zum Aufrufen der API hinzugefügt werden kann. Wenn das Token zwischengespeichert wurde oder der Dienst ohne Benutzerinteraktion ein neues Zugriffstoken bereitstellen kann, wird die Tokenanforderung erfolgreich ausgeführt. Andernfalls schlägt die Tokenanforderung mit einer AccessTokenNotAvailableException fehl, die in einer try-catch-Anweisung abgefangen wird.

Um das eigentliche Token abzurufen, das in die Anforderung aufgenommen werden soll, muss die App überprüfen, ob die Anforderung erfolgreich war, indem tokenResult.TryGetToken(out var token) aufgerufen wird.

Wenn die Anforderung erfolgreich ausgeführt wurde, wird die Tokenvariable mit dem Zugriffstoken aufgefüllt. Die AccessToken.Value-Eigenschaft des Tokens macht die Literalzeichenfolge verfügbar, die im Authorization-Anforderungsheader enthalten sein soll.

Wenn bei der Anforderung ein Fehler aufgetreten ist, weil das Token ohne Benutzerinteraktion nicht bereitgestellt werden konnte, geschieht Folgendes:

  • ASP.NET Core in .NET 7 oder höher: Die App navigiert mit den angegebenen AccessTokenResult.InteractionOptions zu AccessTokenResult.InteractiveRequestUrl, um die Aktualisierung des Zugriffstokens zu ermöglichen.
  • ASP.NET Core in .NET 6 oder früher: Das Tokenergebnis enthält eine Umleitungs-URL. Wenn der Benutzer zu dieser URL navigiert, gelangt er zur Anmeldeseite und nach einer erfolgreichen Authentifizierung zurück zur aktuellen Seite.
@page "/fetchdata"
@using Microsoft.AspNetCore.Authorization
@using Microsoft.AspNetCore.Components.WebAssembly.Authentication
@using {APP NAMESPACE}.Shared
@attribute [Authorize]
@inject HttpClient Http

...

@code {
    private WeatherForecast[] forecasts;

    protected override async Task OnInitializedAsync()
    {
        try
        {
            forecasts = await Http.GetFromJsonAsync<WeatherForecast[]>("WeatherForecast");
        }
        catch (AccessTokenNotAvailableException exception)
        {
            exception.Redirect();
        }
    }
}

Verwenden eines Azure Active Directory B2C-Mandanten

Wenn die App in einem Azure Active Directory B2C-Mandanten registriert ist, wie im Tutorial: Erstellen eines Azure Active Directory B2C-Mandanten beschrieben wird, jedoch dem Leitfaden dieses Artikels folgt, wird der App-ID-URI von ME-ID anders verwaltet.

Sie können den Mandantentyp eines vorhandenen Mandanten überprüfen, indem Sie oben in der ME-ID-Organisationsübersicht den Link Mandanten verwalten auswählen. Überprüfen Sie den Spaltenwert des Mandantentyps für die Organisation. Dieser Abschnitt bezieht sich auf Apps, die den Anweisungen in diesem Artikel folgen, aber in einem Azure Active Directory B2C-Mandanten registriert sind.

Anstelle des App-ID-URI, der dem Format api://{SERVER API APP CLIENT ID OR CUSTOM VALUE}entspricht, weist der App-ID-URI das Format https://{TENANT}.onmicrosoft.com/{SERVER API APP CLIENT ID OR CUSTOM VALUE} auf. Dieser Unterschied wirkt sich auf die Konfigurationen für die Server- und Client-App aus:

  • Legen Sie für die Server-API-App den Eintrag Audience in der App-Einstellungsdatei (appsettings.json) so fest, dass er der Zielgruppe der App (App-ID-URI) entspricht, die vom Azure-Portal ohne nachgestellten Schrägstrich bereitgestellt wird:

    "Audience": "https://{TENANT}.onmicrosoft.com/{SERVER API APP CLIENT ID OR CUSTOM VALUE}"

    Beispiel:

    "Audience": "https://contoso.onmicrosoft.com/41451fa7-82d9-4673-8fa5-69eff5a761fd"

  • Legen Sie in der Program-Datei der Client-App die Zielgruppe (audience) des Bereichs (App-ID-URI) so fest, dass sie der Zielgruppe der Server-API-App entspricht:

    options.ProviderOptions.DefaultAccessTokenScopes
    .Add("https://{TENANT}.onmicrosoft.com/{SERVER API APP CLIENT ID OR CUSTOM VALUE}/{DEFAULT SCOPE}");

    Im vorherigen Bereich ist der App-ID-URI bzw. die Zielgruppe (audience) der Teil https://{TENANT}.onmicrosoft.com/{SERVER API APP CLIENT ID OR CUSTOM VALUE} des Werts, der keinen nachgestellten Schrägstrich (/) enthält und den Bereichsnamen ({DEFAULT SCOPE}) nicht enthält.

    Beispiel:

    options.ProviderOptions.DefaultAccessTokenScopes
    .Add("https://contoso.onmicrosoft.com/41451fa7-82d9-4673-8fa5-69eff5a761fd/API.Access");

    Im vorherigen Bereich ist der App-ID-URI bzw. die Zielgruppe (audience) der Teil https://contoso.onmicrosoft.com/41451fa7-82d9-4673-8fa5-69eff5a761fd des Werts, der keinen nachgestellten Schrägstrich (/) enthält und den Bereichsnamen (API.Access) nicht enthält.

Verwenden eines benutzerdefinierten App-ID-URI

Wenn der App-ID-URI ein benutzerdefinierter Wert ist, müssen Sie den Standardzugriffstokenbereichs-URI in der Client-App manuell aktualisieren und die Benutzergruppe zur ME-ID-Konfiguration der Server-App hinzufügen.

Wichtig

Die folgende Konfiguration ist nicht erforderlich, wenn Sie den standardmäßigen App-ID-URI von api://{SERVER API APP CLIENT ID} verwenden.

Beispiel des App-ID-URI von urn://custom-app-id-uri und ein Bereichsname von API.Access:

  • In der Program-Datei der Client-App:

    options.ProviderOptions.DefaultAccessTokenScopes.Add(
    "urn://custom-app-id-uri/API.Access");

  • Fügen Sie in appsettings.json der Server-App einen Audience-Eintrag mit ausschließlich dem App-ID-URI und keinem nachgestellten Schrägstrich hinzu:

    "Audience": "urn://custom-app-id-uri"

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:

    • 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 Angreifern ausgenutzt werden könnte, lesen Sie bitte den Abschnitt Melden von Sicherheitsproblemen und Fehlern (dotnet/aspnetcoreGitHub 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:

  • cookies für Benutzeranmeldung
  • cookies für App
  • 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.

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 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/5cc15ea8-a296-4aa3-97e4-226dcc9ad298/v2.0/",
  "sub": "5ee963fb-24d6-4d72-a1b6-889c6e2c7438",
  "aud": "70bde375-fce3-4b82-984a-b247d823a03f",
  "nonce": "b2641f54-8dc4-42ca-97ea-7f12ff4af871",
  "iat": 1610055829,
  "auth_time": 1610055822,
  "idp": "idp.com",
  "tfp": "B2C_1_signupsignin"
}.[Signature]

Zusätzliche Ressourcen