Schützen der Blazor WebAssembly von ASP.NET Core

Blazor WebAssembly-Apps werden auf die gleiche Weise geschützt wie Single-Page-Anwendungen (SPAs). Es gibt mehrere Ansätze für die Authentifizierung von Benutzern bei SPAs, der gängigste und umfassendste Ansatz besteht jedoch darin, eine auf dem OAuth 2.0-Protokoll basierende Implementierung wie Open ID Connect (OIDC) zu verwenden.

Die Sicherheitsdokumentation für Blazor WebAssembly konzentriert sich in erster Linie darauf, wie Benutzerauthentifizierungs- und Autorisierungsaufgaben ausgeführt werden. Informationen zur Abdeckung allgemeiner OAuth 2.0/OIDC-Konzepte finden Sie in den Ressourcen im Abschnitt Zusätzliche Ressourcen des Hauptübersichtsartikels.

Clientseitige/SPA-Sicherheit vertraulicher Daten und Anmeldeinformationen

Die .NET-/C#-Codebasis einer Blazor WebAssembly-App wird für Clients bereitgestellt, und der Code der App kann nicht vor der Begutachtung und Manipulation durch Benutzer*innen geschützt werden. Platzieren Sie vertrauliche Daten niemals in einer Blazor WebAssembly-App, z. B. Geheime App-Schlüssel, Verbindungszeichenfolgen, Kennwörter, Sicherheitsschlüssel und privaten .NET/C#-Code.

Die folgenden Technologien sind nützlich zum Speichern vertraulicher Daten, die in derselben App zusammen verwendet werden können, um Verantwortlichkeiten für das Speichern von Daten zwischen Entwicklungs- und Staging-/Produktionsumgebungen aufzuteilen:

• Geheimer Manager-Tool: Wird nur im lokalen Entwicklungssystem verwendet.
• Azure Key Vault: Kann für lokal ausgeführte Apps in der Entwicklungsumgebung und für Staging-/Produktionsbereitstellungen verwendet werden.

Beispiele für die vorherigen Ansätze finden Sie unter Kontobestätigung und Kennwortwiederherstellung in ASP.NET Core Blazor WebAssembly mit ASP.NET Core-Identity.

Web-API-Anforderungen

Um .NET/C#-Code und -Daten zu schützen, verwenden Sie ASP.NET Core Data Protection Features mit einer serverseitigen ASP.NET Core-Back-End-Web-API. Die clientseitige Blazor WebAssembly App ruft die serverseitige Web-API für sichere App-Features und Datenverarbeitung auf. Weitere Informationen finden Sie unter Aufrufen einer Web-API aus einer ASP.NET Core Blazor-App- sowie den Artikeln und Beispielen in diesem Dokumentationsknoten.

Blazor WebAssembly-Apps werden aufgrund von Sicherheit bei der Ressourcenfreigabe zwischen verschiedenen Ursprüngen (CORS, Cross-Origin Request Sharing) häufig daran gehindert, direkte Aufrufe über Ursprünge hinweg an Web-APIs vorzunehmen. Eine typische Ausnahme sieht wie folgt aus:

Der Zugriff auf Fetch unter „{URL}“ vom Ursprung https://localhost:{PORT}' wurde durch die CORS-Richtlinie blockiert: In der angeforderten Ressource ist kein „Access-Control-Allow-Origin“-Header vorhanden. Wenn eine undurchsichtige Antwort Ihren Anforderungen entspricht, legen Sie den Modus der Anforderung auf "no-cors" fest, um die Ressource mit CORS deaktiviert abzurufen.

Auch wenn Sie SetBrowserRequestMode mit einem BrowserRequestMode Feld von NoCors (1) aufrufen, das die vorherige Ausnahme umgehen möchte, schlägt die Anforderung in der Regel aufgrund von CORS-Einschränkungen für den Ursprung der Web-API fehl, z. B. eine Einschränkung, die nur Aufrufe von bestimmten Ursprüngen oder eine Einschränkung zulässt, die JavaScript-fetch Anforderungen von einem Browser verhindert. Die einzige Möglichkeit, dass solche Aufrufe Erfolg haben, besteht darin, dass die von Ihnen aufgerufene Web-API dem Ursprung erlaubt, seinen Ursprung mit der richtigen CORS-Konfiguration aufzurufen. Die meisten externen Web-APIs ermöglichen es Ihnen nicht, ihre CORS-Richtlinien zu konfigurieren. Um mit dieser Einschränkung umzugehen, nehmen Sie eine der folgenden Strategien ein:

• Verwalten Sie Ihre eigene serverseitige ASP.NET Core-Back-End-Web-API. Die clientseitige Blazor WebAssembly-App ruft Ihre serverseitige Web-API auf, und Ihre Web-API sendet die Anforderung vom serverbasierten C#-Code (kein Browser) an die externe Web-API mit den richtigen CORS-Headern und gibt das Ergebnis an Ihre clientseitige Blazor WebAssembly App zurück.

• Verwenden Sie einen Proxydienst, um die Anforderung von der clientseitigen Blazor WebAssembly-App an die externe Web-API zu proxyn. Der Proxydienst verwendet eine serverseitige App, um die Anforderung im Auftrag des Clients zu senden und das Ergebnis zurück, nachdem der Aufruf erfolgreich war. Im folgenden Beispiel, das auf CloudFlare's CORS PROXY basiert, ist der {REQUEST URI}-Platzhalter der Anforderungs-URI:

  @using System.Net
  @inject IHttpClientFactory ClientFactory
  
  ...
  
  @code {
      public async Task CallApi()
      {
          var client = ClientFactory.CreateClient();
  
          var urlEncodedRequestUri = WebUtility.UrlEncode("{REQUEST URI}");
  
          var request = new HttpRequestMessage(HttpMethod.Get, 
              $"https://corsproxy.io/?{urlEncodedRequestUri}");
  
          var response = await client.SendAsync(request);
  
          ...
      }
  }
  

Authentifizierungsbibliothek

Blazor WebAssembly unterstützt die Authentifizierung und Autorisierung von Apps mithilfe von OIDC über die Microsoft.AspNetCore.Components.WebAssembly.Authentication-Bibliothek unter Verwendung der Microsoft-Identitätsplattform. Die Bibliothek stellt mehrere Primitive für die nahtlose Authentifizierung für ASP.NET Core-Back-Ends bereit. Die Bibliothek kann bei einem Drittanbieter-Identitätsanbieter authentifiziert werden, der OIDC unterstützt (die OpenID-Anbieter).

Die Authentifizierungsunterstützung in der Blazor WebAssembly-Bibliothek (Authentication.js) basiert auf der Microsoft-Authentifizierungsbibliothek (MSAL, msal.js), die für die Verarbeitung der zugrunde liegenden Informationen im Authentifizierungsprotokoll verwendet wird. Die Blazor WebAssembly-Bibliothek unterstützt nur den Prüfschlüssel für den Flow für den PKCE-Autorisierungscode (Proof Key for Code Exchange, Prüfschlüssel für Codeaustausch). Die implizite Gewährung wird nicht unterstützt.

Eine weitere Option zum Authentifizieren von SPAs ist die Verwendung von SameSite-Cookies. Das Entwurfsdesign von Blazor WebAssembly verwendet jedoch OAuth und OIDC als beste Option für die Authentifizierung bei Blazor WebAssembly-Apps. Die auf JSON Web Token gestützte tokenbasierte Authentifizierung wurde aus Funktions- und Sicherheitsgründen der cookiebasierten Authentifizierung vorgezogen.

• Die Verwendung eines tokenbasierten Protokolls bietet weniger Schwachstellen, da die Token nicht in allen Anfragen gesendet werden.
• Die Token werden explizit an den Server gesendet, so dass Serverendpunkte nicht gegen websiteübergreifende Anforderungsfälschung (CSRF) geschützt werden müssen. Dadurch können Sie Blazor WebAssembly-Apps zusammen mit MVC- oder Razor Pages-Apps hosten.
• Token haben eingeschränktere Berechtigungen als Cookies. Beispielsweise können Token nicht zum Verwalten des Benutzerkontos oder zur Änderung eines Benutzerkennworts verwendet werden, es sei denn, diese Funktionalität wird explizit implementiert.
• Die Token haben eine kurze Lebensdauer von einer Stunde, was das Angriffsfenster begrenzt. Token können auch zu jeder Zeit widerrufen werden.
• Eigenständige JWTs bieten dem Client und dem Server Garantien zum Authentifizierungsprozess. Ein Client verfügt zum Beispiel über die Mittel, um zu erkennen und zu überprüfen, dass die von ihm empfangenen Token legitim sind und im Rahmen eines bestimmten Authentifizierungsprozesses ausgegeben wurden. Wenn Dritte versuchen, ein Token inmitten des Authentifizierungsprozesses zu tauschen, kann der Client das ausgetauschte Token erkennen und so die Nutzung vermeiden.
• Token mit OAuth und OIDC sind nicht vom ordnungsgemäßen Verhalten des Benutzer-Agents und davon abhängig, dass dieser gewährleistet, dass die App sicher ist.
• Tokenbasierte Protokolle wie OAuth und OIDC ermöglichen die Authentifizierung und Autorisierung von Benutzern in eigenständigen BlazorWebassembly-Anwendungen mit denselben Sicherheitsmerkmalen.

Wichtig

Bei ASP.NET Core-Versionen, die Duende Identity Server in Blazor-Projektvorlagen verwenden, fordert Duende Software möglicherweise die Zahlung einer Lizenzgebühr für die Verwendung von Duende Identity Server in Produktionsumgebungen. Weitere Informationen finden Sie unter Migrieren von ASP.NET Core 5.0 zu 6.0.

Authentifizierungsprozess mit OIDC

Die Microsoft.AspNetCore.Components.WebAssembly.Authentication-Bibliothek bietet mehrere Primitive zum Implementieren der Authentifizierung und Autorisierung mithilfe von OIDC. Im Allgemeinen funktioniert die Authentifizierung wie folgt:

• Wenn ein anonymer Benutzer die Anmeldeschaltfläche auswählt oder eine Razor-Komponente oder -Seite mit angewendetem [Authorize]-Attribut anfordert, wird der Benutzer zur Anmeldeseite (/authentication/login) der App weitergeleitet.
• Auf der Anmeldeseite bereitet die Authentifizierungsbibliothek eine Umleitung zum Autorisierungsendpunkt vor. Der Autorisierungsendpunkt befindet sich außerhalb der Blazor WebAssembly-App und kann als separater Ursprung gehostet werden. Der Endpunkt ist dafür verantwortlich, zu bestimmen, ob der Benutzer authentifiziert ist, und dass ein oder mehrere Token als Antwort ausgegeben werden. Die Authentifizierungsbibliothek stellt einen Anmelderückruf zum Empfangen der Authentifizierungsantwort bereit.
  • Wenn der Benutzer nicht authentifiziert ist, wird er an das zugrunde liegende Authentifizierungssystem umgeleitet (normalerweise ASP.NET Core Identity).
  • Wenn der Benutzer bereits authentifiziert wurde, generiert der Authentifizierungsendpunkt die entsprechenden Token und leitet den Browser zurück an den Anmelderückrufendpunkt (/authentication/login-callback).
• Wenn die Blazor WebAssembly-App den Anmelderückrufendpunkt (/authentication/login-callback) lädt, wird die Authentifizierungsantwort verarbeitet.
  • Sobald der Authentifizierungsprozess erfolgreich abgeschlossen wird, wird der Benutzer authentifiziert und optional an die ursprüngliche geschützte URL weitergeleitet, die vom Benutzer angefordert wurde.
  • Sollte der Authentifizierungsprozess aus irgendeinem Grund nicht funktionieren, wird der Benutzer auf eine Seite weitergeleitet, auf der ein Fehler angezeigt wird (/authentication/login-failed).

Authentication-Komponente

Die Authentication-Komponente (Authentication.razor) behandelt Remote-Authentifizierungsvorgänge und ermöglicht der App Folgendes:

• Konfigurieren von App-Routen für Authentifizierungsstatus.
• Festlegen von Inhalten der Benutzeroberfläche für Authentifizierungsstatus.
• Verwalten des Authentifizierungsstatus.

Authentifizierungsaktionen, wie etwa das Registrieren oder Anmelden eines Benutzers, werden der Blazor-Komponente des RemoteAuthenticatorViewCore<TAuthenticationState>-Frameworks übergeben, die für die übergreifende Dauerhaftigkeit und die Steuerung des Status über Authentifizierungsvorgänge hinweg zuständig ist.

Weitere Informationen und Beispiele finden Sie unter Zusätzliche Sicherheitsszenarien für Blazor WebAssembly in ASP.NET Core.

Autorisierung

In Blazor WebAssembly-Apps können Autorisierungsprüfungen umgangen werden, da der gesamte clientseitige Code von Benutzern geändert werden kann. Dasselbe gilt für alle clientseitigen App-Technologien, einschließlich JavaScript SPA-Frameworks oder native Apps für jedes Betriebssystem.

Führen Sie Autorisierungsprüfungen auf dem Server immer innerhalb aller API-Endpunkte durch, auf die Ihre clientseitige App zugreift.

Anpassen der Authentifizierung

Blazor WebAssembly stellt Methoden zum Hinzufügen und Abrufen zusätzlicher Parameter für die zugrunde liegende Authentifizierungsbibliothek bereit, um Remoteauthentifizierungsvorgänge mit externen Identitätsanbietern durchzuführen.

Um zusätzliche Parameter zu übergeben, unterstützt NavigationManager das Übergeben und Abrufen des Verlaufseintragsstatus beim Ausführen von Änderungen an externen Speicherorten. Weitere Informationen finden Sie in den folgenden Ressourcen:

• BlazorGrundlagen>Routing und Navigation: Artikel
  • Navigationsverlaufsstatus
  • Navigationsoptionen
• MDN-Dokumentation: Verlaufs-API

Der von der Verlaufs-API gespeicherte Status bietet die folgenden Vorteile für Remoteauthentifizierung:

• Der Status, der an den gesicherten App-Endpunkt übergeben wird, ist an die Navigation gebunden, die zum Authentifizieren des Benutzers am authentication/login-Endpunkt ausgeführt wird.
• Zusätzlicher Aufwand für die Codierung und Decodierung der Daten wird vermieden.
• Sicherheitsrisiken werden reduziert. Im Gegensatz zur Verwendung einer Abfragezeichenfolge zum Speichern des Navigationsstatus kann eine Navigation auf oberster Ebene oder ein Einfluss eines anderen Ursprungs den von der Verlaufs-API gespeicherten Status nicht festlegen.
• Der Verlaufseintrag wird bei erfolgreicher Authentifizierung ersetzt, sodass der an den Verlaufseintrag angefügte Status entfernt wird und keine Bereinigung erforderlich ist.

InteractiveRequestOptions stellt die Anforderung an den Identitätsanbieter für die Anmeldung oder das Bereitstellen eines Zugriffstokens dar.

NavigationManagerExtensions stellt die NavigateToLogin-Methode für einen Anmeldevorgang und NavigateToLogout für einen Abmeldevorgang bereit. Die Methoden rufen NavigationManager.NavigateTo auf, wobei der Verlaufseintragsstatus mit übergebenen InteractiveRequestOptions oder einer neuen InteractiveRequestOptions-Instanz festgelegt wird, die von der Methode für die folgenden Vorgänge erstellt wird:

• Ein Benutzer meldet sich mit dem aktuellen URI für die Rückgabe-URL an (InteractionType.SignIn).
• Ein Benutzer meldet sich mit der Rückgabe-URL ab (InteractionType.SignOut).

Die folgenden Authentifizierungsszenarien werden im Artikel zu den zusätzlichen Sicherheitsszenarien in ASP.NET Core Blazor WebAssembly behandelt:

• Anpassen des Anmeldevorgangs
• Abmelden mit einer benutzerdefinierten Rückgabe-URL
• Anpassen von Optionen vor dem interaktiven Abrufen eines Tokens
• Anpassen von Optionen bei Verwendung eines IAccessTokenProvider
• Abrufen des Anmeldepfads aus Authentifizierungsoptionen

Autorisierung für die gesamte App erforderlich

Wenden Sie das [Authorize]-Attribut (API-Dokumentation) mit Razor der folgenden Ansätze auf jede -Komponente der App an:

• Fügen Sie in der Imports-Datei der App eine @using-Direktive für den Microsoft.AspNetCore.Authorization-Namespace mit einer @attribute-Direktive für das [Authorize]-Attribut hinzu.

  _Imports.razor:

  @using Microsoft.AspNetCore.Authorization
  @attribute [Authorize]
  

  Lassen Sie anonymen Zugriff auf die Authentication-Komponente zu, um die Umleitung an den Identitätsanbieter zu ermöglichen. Fügen Sie der Razor-Komponente unter ihrer Authentication-Anweisung den folgenden @page-Code hinzu.

  Authentication.razor:

  @using Microsoft.AspNetCore.Components.WebAssembly.Authentication
  @attribute [AllowAnonymous]
  

• Fügen Sie das Attribut zu jeder Razor Komponente unter der @page Anweisung hinzu:

  @using Microsoft.AspNetCore.Authorization
  @attribute [Authorize]
  

Hinweis

Das Festlegen einer AuthorizationOptions.FallbackPolicy auf eine Richtlinie mit RequireAuthenticatedUser wird nicht unterstützt.

Verwenden einer Identitätsanbieter-App-Registrierung pro App

Einige der Artikel unter dieser Übersicht beziehen sich auf Blazor-Hostingszenarien, die zwei oder mehr Apps umfassen. Eine eigenständige Blazor WebAssembly-App verwendet eine Web-API mit authentifizierten Benutzern, um auf Serverressourcen und Daten zuzugreifen, die von einer Server-App bereitgestellt werden.

Wenn diese Szenarien in Dokumentationsbeispielen implementiert sind, werden zwei Identitätsanbieterregistrierungen verwendet: eine für die Client-App und eine für die Server-App. Die Verwendung separater Registrierungen, z. B. in Microsoft Entra ID, ist nicht unbedingt erforderlich. Die Verwendung von zwei Registrierungen ist jedoch eine Best Practice für die Sicherheit, da die Registrierungen nach App isoliert werden. Die Verwendung separater Registrierungen ermöglicht auch eine unabhängige Konfiguration der Client- und Serverregistrierungen.

Aktualisierungstoken

Aktualisierungstoken können in Blazor WebAssembly-Apps zwar nicht gesichert, aber verwendet werden, wenn Sie sie mit entsprechenden Sicherheitsstrategien implementieren.

Für eigenständige Blazor WebAssembly-Apps in ASP.NET Core in .NET 6 oder höher empfehlen wir Folgendes:

• Den OAuth 2.0-Autorisierungscodeflow (Code) mit Proof Key for Code Exchange (PKCE).
• Ein Aktualisierungstoken mit kurzem Ablaufzeitraum.
• Ein rotiertes Aktualisierungstoken.
• Ein Aktualisierungstoken mit Ablauf, nach dem ein neuer interaktiver Autorisierungsflow erforderlich ist, um die Anmeldeinformationen des Benutzers zu aktualisieren.

Weitere Informationen finden Sie in den folgenden Ressourcen:

• Microsoft Identity Platform-Aktualisierungstoken: Lebensdauer von Aktualisierungstoken
• OAuth 2.0 für browserbasierte Apps (IETF-Spezifikation)

Erstellen von Ansprüchen für Benutzer

Apps fordern häufig Ansprüche für Benutzer basierend auf einem Web-API-Aufruf an einen Server an. Beispielsweise werden Ansprüche häufig bei der Autorisierung in Apps verwendet. In diesen Szenarien fordert die App ein Zugriffstoken für den Zugriff auf den Dienst an und verwendet dieses Token zum Abrufen der Benutzerdaten für die Erstellung von Ansprüchen.

Beispiele finden Sie in den folgenden Ressourcen:

• Zusätzliche Szenarios: Anpassen des Benutzers
• ASP.NET Core Blazor WebAssembly mit Microsoft Entra-ID-Gruppen und -Rollen

Unterstützung für das Vorabrendering

Vorabrendering wird für Authentifizierungsendpunkte (/authentication/-Pfadsegment) nicht unterstützt.

Weitere Informationen finden Sie unter Zusätzliche Sicherheitsszenarien für Blazor WebAssembly in ASP.NET Core.

Azure App Service für Linux mit Identity Server

Geben Sie den Zertifikataussteller explizit an, wenn Sie eine Bereitstellung auf Azure App Service für Linux mit Identity Server durchführen.

Weitere Informationen finden Sie unter Verwenden von Identity zum Sichern eines Web-API-Back-Ends für SPAs.

Windows-Authentifizierung

Es wird nicht empfohlen, die Windows-Authentifizierung mit Blazor WebAssembly oder mit einem anderen SPA-Framework zu verwenden. Wir empfehlen die Verwendung von tokenbasierten Protokollen anstelle der Windows-Authentifizierung, z. B. OIDC mit Active Directory-Verbunddiensten (ADFS).

Wenn die Windows-Authentifizierung mit Blazor WebAssembly oder mit einem anderen SPA-Framework verwendet wird, sind weitere Maßnahmen nötig, um die App vor Token für siteübergreifende Anforderungsfälschung (CSRF) zu schützen. Die gleichen Probleme, die auf Cookies zutreffen, gelten auch für die Windows-Authentifizierung mit dem Zusatz, dass die Windows-Authentifizierung keine Mechanismen bietet, um eine ursprungsübergreifende Freigabe des Authentifizierungskontexts zu verhindern. Apps, die die Windows-Authentifizierung ohne zusätzlichen Schutz vor siteübergreifender Anforderungsfälschung verwenden, sollten zumindest auf das Intranet einer Organisation beschränkt sein und nicht im offenen Internet verwendet werden.

Weitere Informationen finden Sie unter Prevent Cross-Site Request Forgery (XSRF/CSRF) Attacks in ASP.NET Core (Verhindern von websiteübergreifenden Anforderungsfälschungen (XSRF/CSRF) in ASP.NET Core).

Schützen eines SignalR-Hubs

Um einen SignalR-Hub im Server-API-Projekt zu sichern, wenden Sie das [Authorize]-Attribut auf die Hubklasse oder auf Methoden der Hubklasse an.

Weitere Informationen zu einem Clientprojekt mit Voarabrendering, wie z. B. gehostetes Blazor WebAssembly (ASP.NET Core in .NET 7 oder früher) oder ein Blazor Web App (ASP.NET Core in .NET 8 oder höher), finden Sie in der Anleitung im ASP.NET Core BlazorSignalR-Leitfaden.

In einer Client-Projektkomponente ohne Prerendering, wie z. B. Standalone- Blazor WebAssembly oder Nicht-Browser-Anwendungen, geben Sie ein Zugriffstoken an die Hub-Verbindung weiter, wie das folgende Beispiel zeigt. Weitere Informationen hierzu finden Sie unter Authentifizierung und Autorisierung in ASP.NET Core SignalR.

@using Microsoft.AspNetCore.Components.WebAssembly.Authentication
@inject IAccessTokenProvider TokenProvider
@inject NavigationManager Navigation

...

var tokenResult = await TokenProvider.RequestAccessToken();

if (tokenResult.TryGetToken(out var token))
{
    hubConnection = new HubConnectionBuilder()
        .WithUrl(Navigation.ToAbsoluteUri("/chathub"), 
            options => { options.AccessTokenProvider = () => Task.FromResult(token?.Value); })
        .Build();

  ...
}

Logging

Dieser Abschnitt gilt für Blazor WebAssembly-Apps in ASP.NET Core in .NET 7 oder höher.

Informationen zum Aktivieren der Debug- oder Ablaufverfolgungsprotokollierung finden Sie im Abschnitt Authentifizierungsprotokollierung (Blazor WebAssembly) im Artikel zur ASP.NET Core-Blazor-Protokollierung für Version 7.0 oder höher.

Die WebAssembly-Sandbox

Die WebAssembly-Sandbox beschränkt den Zugriff auf die Umgebung des Systems, das WebAssembly-Code ausführt, einschließlich des Zugriffs auf E/A-Subsysteme, Systemspeicher und -ressourcen sowie das Betriebssystem. Die Isolierung zwischen WebAssembly-Code und dem System, das den Code ausführt, macht WebAssembly zu einem sicheren Codierungsframework für Systeme. WebAssembly ist jedoch anfällig für Seitenkanalangriffe auf Hardwareebene. Lassen Sie bei der Beschaffung von Hardware sowie dem Einrichten von Einschränkungen für den Zugriff auf Hardware normale Vorsichtsmaßnahmen und angemessene Sorgfalt walten.

WebAssembly befindet sich nicht im Besitz von Microsoft und wird nicht von Microsoft verwaltet.

Weitere Informationen finden Sie in den folgenden W3C-Ressourcen:

• WebAssembly: Security (Sicherheit)
• WebAssembly Specification: Security Considerations (WebAssembly-Spezifikation: Sicherheitsüberlegungen)
• W3C WebAssembly Community Group: Feedback and issues (W3C-WebAssembly-Communitygruppe: Feedback und Probleme): Der Link zur W3C-WebAssembly-Communitygruppe wird nur zu Referenzzwecken bereitgestellt und dient zur Klarstellung, dass WebAssembly-Sicherheitslücken und -Bugs regelmäßig gepatcht, häufig gemeldet und browserbasiert behoben werden. Senden Sie kein Feedback und keine Bugberichte zu Blazor an die W3C-WebAssembly-Communitygruppe.Blazor-Feedback sollte nur an die Microsoft ASP.NET Core-Produkteinheit gesendet werden. Wenn die Microsoft-Produkteinheit feststellt, dass ein zugrunde liegendes Problem mit WebAssembly vorliegt, führt sie die entsprechenden Schritte aus, um das Problem der W3C-WebAssembly-Communitygruppe zu melden.

Implementierungsleitfaden

Artikel unter dieser Übersicht bieten Informationen zum Authentifizieren von Benutzern in Blazor WebAssembly-Apps für bestimmte Anbieter.

Eigenständige Blazor WebAssembly-Apps:

• Allgemeiner Leitfaden für OIDC-Anbieter und die WebAssembly-Authentifizierungsbibliothek
• Microsoft-Konten
• Microsoft Entra-ID (ME-ID)
• Azure Active Directory (AAD) B2C

Weitere Konfigurationsanleitungen finden Sie in den folgenden Artikeln:

• Zusätzliche Sicherheitsszenarios für Blazor WebAssembly in ASP.NET Core
• Verwenden der Graph-API mit in ASP.NET CoreBlazor WebAssembly

Verwenden des Autorisierungscodeflows mit PKCE

DieMicrosoft-Authentifizierungsbibliothek für JavaScript (MSAL) v2.0 oder höher von Microsoft Identity Platform bietet Unterstützung für den Autorisierungscodeflow mit Proof Key for Code Exchange (PKCE) und der Ressourcenfreigabe zwischen verschiedenen Ursprüngen (CORS, Cross-Origin Resource Sharing) für Single-Page-Webanwendungen, einschließlich Blazor.

Microsoft empfiehlt die Verwendung der impliziten Gewährung nicht.

Weitere Informationen finden Sie in den folgenden Ressourcen:

• Unterstützung des Authentifizierungsablaufs in MSAL: Implizite Gewährung
• Microsoft Identity Platform und impliziter Genehmigungsablauf: Bevorzugen des Autorisierungscodeflusses
• Microsoft Identity Platform und des OAuth 2.0-Autorisierungscodeflusses

Zusätzliche Ressourcen

• Dokumentation zu Microsoft Identity Platform
  • Allgemeine Dokumentation
  • Zugriffstoken
• Konfigurieren von ASP.NET Core zur Verwendung mit Proxyservern und Lastenausgleich
  • 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.
• Vorabrendering mit Authentifizierung
• WebAssembly: Security (Sicherheit)
• WebAssembly Specification: Security Considerations (WebAssembly-Spezifikation: Sicherheitsüberlegungen)