Delen via

Beveilig ASP.NET Core Blazor WebAssembly

  • Artikel

Notitie

Dit is niet de nieuwste versie van dit artikel. Zie de .NET 9-versie van dit artikelvoor de huidige release.

Waarschuwing

Deze versie van ASP.NET Core wordt niet meer ondersteund. Zie de .NET- en .NET Core-ondersteuningsbeleidvoor meer informatie. Zie de .NET 9-versie van dit artikelvoor de huidige release.

Belangrijk

Deze informatie heeft betrekking op een pre-releaseproduct dat aanzienlijk kan worden gewijzigd voordat het commercieel wordt uitgebracht. Microsoft geeft geen garanties, uitdrukkelijk of impliciet, met betrekking tot de informatie die hier wordt verstrekt.

Zie de .NET 9-versie van dit artikelvoor de huidige release.

Blazor WebAssembly apps worden op dezelfde manier beveiligd als toepassingen met één pagina (SPA's). Er zijn verschillende benaderingen voor het verifiëren van gebruikers voor SPA's, maar de meest voorkomende en uitgebreide benadering is het gebruik van een implementatie op basis van het OAuth 2.0-protocol, zoals OpenID Connect (OIDC).

De Blazor WebAssembly beveiligingsdocumentatie is voornamelijk gericht op het uitvoeren van gebruikersverificatie- en autorisatietaken. Zie voor de algemene concepten van OAuth 2.0/OIDC de resources in de hoofdoverzichtsartikel, sectie Aanvullende resources.

Beveiliging van gevoelige gegevens en inloggegevens aan de klantzijde/SPAs

De .NET/C#-codebasis van een Blazor WebAssembly-app wordt aan clients aangeboden en de code van de app kan niet worden beveiligd tegen inspectie en manipulatie door gebruikers. Plaats nooit gevoelige gegevens in een Blazor WebAssembly-app, zoals app-geheimen, verbindingsreeksen, wachtwoorden, beveiligingssleutels en persoonlijke .NET/C#-code.

De volgende technologieën zijn handig voor het opslaan van gevoelige gegevens, die samen in dezelfde app kunnen worden gebruikt om verantwoordelijkheden op te splitsen voor het opslaan van gegevens tussen ontwikkel- en faserings-/productieomgevingen:

Zie accountbevestiging en wachtwoordherstel in ASP.NET Core Blazor WebAssembly met ASP.NET Core Identityvoor voorbeelden van de voorgaande benaderingen.

Web-API-aanvragen

Als u .NET/C#-code en -gegevens wilt beveiligen, gebruikt u ASP.NET Core Data Protection--functies met een ASP.NET Core-back-endweb-API. De Blazor WebAssembly-app aan de clientzijde roept de web-API aan de serverzijde aan voor beveiligde app-functies en gegevensverwerking. Zie Een web-API aanroepen vanuit een ASP.NET Core Blazor-app en de artikelen en voorbeelden in dit documentatieknooppunt voor meer informatie.

Blazor WebAssembly apps worden vaak verhinderd om directe oproepen te maken tussen origins naar web-API’s vanwege de CORS-beveiliging (Cross-Origin Request Sharing). Een typische uitzondering ziet er als volgt uit:

Toegang tot ophalen op {URL} van oorsprong 'https://localhost:{PORT}' is geblokkeerd door CORS-beleid: er is geen header Access-Control-Allow-Origin aanwezig op de aangevraagde resource. Als een ondoorzichtig antwoord aan uw behoeften voldoet, stelt u de modus van de aanvraag in op 'no-cors' om de resource op te halen waarvoor CORS is uitgeschakeld.

Zelfs als u SetBrowserRequestMode aanroept met een BrowserRequestMode veld van NoCors (1) om de voorgaande uitzondering te omzeilen, mislukt de aanvraag meestal vanwege CORS-beperkingen op de oorsprong van de web-API, zoals een beperking die alleen aanroepen van specifieke oorsprongen toestaat of een beperking die JavaScript fetch aanvragen van een browser verhindert. De enige manier waarop dergelijke aanroepen kunnen slagen, is dat de web-API die u aanroept het toestaat dat uw oorsprong zijn oorsprong mag aanroepen met de juiste CORS-configuratie. Met de meeste externe web-API's kunt u hun CORS-beleid niet configureren. Als u deze beperking wilt aanpakken, moet u een van de volgende strategieën toepassen:

  • Onderhoud uw eigen ASP.NET Core-back-endweb-API aan de serverzijde. De Blazor WebAssembly-app aan de clientzijde roept uw web-API aan op de server en uw web-API doet de aanvraag vanuit de servergebaseerde C#-code (niet een browser) naar de externe web-API met de juiste CORS-headers, waardoor het resultaat wordt geretourneerd naar de Blazor WebAssembly-app aan de clientzijde.

  • Gebruik een proxyserver om het verzoek van de clientzijde van de Blazor WebAssembly app naar de externe web-API te proxyen. De proxyservice maakt gebruik van een app aan de serverzijde om de aanvraag namens de client in te dienen en retourneert het resultaat nadat de aanroep is geslaagd. In het volgende voorbeeld op basis van CORS PROXY-van CloudFlare is de tijdelijke aanduiding {REQUEST URI} de aanvraag-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);

        ...
    }
}

Authenticatiebibliotheek

Blazor WebAssembly ondersteunt het verifiëren en autoriseren van apps met behulp van OIDC via de Microsoft.AspNetCore.Components.WebAssembly.Authentication-bibliotheek met behulp van het Microsoft Identity Platform. De bibliotheek biedt een set primitieven voor naadloze authenticatie bij ASP.NET Core-back-end. De bibliotheek kan authenticeren tegen elke externe Identity Provider (IP) die OIDC ondersteunt, en die OpenID-providers (OP) worden genoemd.

De verificatieondersteuning in de Blazor WebAssembly Library (Authentication.js) is gebouwd boven op de Microsoft Authentication Library (MSAL, msal.js), die wordt gebruikt om de details van het onderliggende verificatieprotocol af te handelen. De Blazor WebAssembly-bibliotheek ondersteunt alleen de autorisatiecodestroom voor Proof Key for Code Exchange (PKCE). Impliciete toekenning wordt niet ondersteund.

Er bestaan andere opties voor het verifiëren van SPA's, zoals het gebruik van SameSite-cookies. Het technische ontwerp van Blazor WebAssembly maakt echter gebruik van OAuth en OIDC als de beste optie voor verificatie in Blazor WebAssembly apps. verificatie op basis van tokens op basis van JSON-webtokens (JWT's) is gekozen voor cookieverificatie om functionele en beveiligingsredenen:

  • Het gebruik van een protocol op basis van tokens biedt minder beveiligingsproblemen, omdat de tokens niet in alle aanvragen worden verzonden.
  • De tokens worden expliciet naar de server verzonden, zodat servereindpunten geen bescherming vereisen tegen CSRF-(Cross-Site Request Forgery). Hiermee kunt u Blazor WebAssembly apps hosten naast MVC- of Razor pagina-apps.
  • Tokens hebben beperktere machtigingen dan cookies. Tokens kunnen bijvoorbeeld niet worden gebruikt om het gebruikersaccount te beheren of het wachtwoord van een gebruiker te wijzigen, tenzij dergelijke functionaliteit expliciet wordt geïmplementeerd.
  • Tokens hebben een korte levensduur, één uur, waardoor het aanvalsvenster wordt beperkt. Tokens kunnen ook op elk gewenst moment worden ingetrokken.
  • Zelfstandige JWT's bieden garanties voor de client en server over het verificatieproces. Een client heeft bijvoorbeeld de middelen om te detecteren en te valideren dat de tokens die worden ontvangen legitiem zijn en zijn verzonden als onderdeel van een bepaald verificatieproces. Als een derde partij een token midden in het verificatieproces probeert te wijzigen, kan de client het overgeschakelde token detecteren en voorkomen dat het wordt gebruikt.
  • Tokens met OAuth en OIDC zijn niet afhankelijk van de gebruikersagent die correct werkt om ervoor te zorgen dat de app veilig is.
  • Op tokens gebaseerde protocollen, zoals OAuth en OIDC, maken het mogelijk om gebruikers in zelfstandige Blazor Webassembly-apps te verifiëren en autoriseren met dezelfde set beveiligingskenmerken.
  • Het gebruik van een protocol op basis van tokens biedt minder beveiligingsproblemen, omdat de tokens niet in alle aanvragen worden verzonden.
  • De tokens worden expliciet naar de server verzonden, zodat servereindpunten geen bescherming vereisen tegen CSRF-(Cross-Site Request Forgery). Hiermee kunt u Blazor WebAssembly-apps hosten naast MVC-apps of apps voor Razor-pagina's.
  • Tokens hebben beperktere machtigingen dan cookies. Tokens kunnen bijvoorbeeld niet worden gebruikt om het gebruikersaccount te beheren of het wachtwoord van een gebruiker te wijzigen, tenzij dergelijke functionaliteit expliciet wordt geïmplementeerd.
  • Tokens hebben een korte levensduur, één uur, waardoor het aanvalsvenster wordt beperkt. Tokens kunnen ook op elk gewenst moment worden ingetrokken.
  • Zelfstandige JWT's bieden garanties voor de client en server over het verificatieproces. Een client heeft bijvoorbeeld de middelen om te detecteren en te valideren dat de tokens die worden ontvangen legitiem zijn en zijn verzonden als onderdeel van een bepaald verificatieproces. Als een derde partij een token midden in het verificatieproces probeert te wijzigen, kan de client het overgeschakelde token detecteren en voorkomen dat het wordt gebruikt.
  • Tokens met OAuth en OIDC zijn niet afhankelijk van de gebruikersagent die correct werkt om ervoor te zorgen dat de app veilig is.
  • Op tokens gebaseerde protocollen, zoals OAuth en OIDC, zorgen ervoor dat gebruikers van gehoste Blazor WebAssembly-oplossingsclients en zelfstandige Blazor Webassembly-apps met dezelfde set beveiligingskenmerken kunnen verifiëren en autoriseren.

Belangrijk

Voor versies van ASP.NET Core die Duende Identity Server in Blazor projectsjablonen gebruiken, moet Duende Software- mogelijk een licentiekosten betalen voor productiegebruik van Duende Identity Server. Zie Migreren van ASP.NET Core 5.0 naar 6.0voor meer informatie.

Verificatieproces met OIDC

De Microsoft.AspNetCore.Components.WebAssembly.Authentication-bibliotheek biedt verschillende primitieven voor het implementeren van verificatie en autorisatie met behulp van OIDC. In algemene termen werkt verificatie als volgt:

  • Wanneer een anonieme gebruiker de aanmeldingsknop selecteert of een Razor onderdeel of pagina aanvraagt met het [Authorize] kenmerk toegepast, wordt de gebruiker omgeleid naar de aanmeldingspagina van de app (/authentication/login).
  • Op de aanmeldingspagina bereidt de verificatiebibliotheek zich voor op een omleiding naar het autorisatie-eindpunt. Het autorisatie-eindpunt bevindt zich buiten de Blazor WebAssembly-app en kan worden gehost op een afzonderlijke oorsprong. Het eindpunt is verantwoordelijk voor het bepalen of de gebruiker is geverifieerd en voor het uitgeven van een of meer tokens in reactie. De authenticatiebibliotheek biedt een inlogcallback om de authenticatierespons te ontvangen.
    • Als de gebruiker niet is geverifieerd, wordt de gebruiker omgeleid naar het onderliggende verificatiesysteem. Dit is meestal ASP.NET Core Identity.
    • Als de gebruiker al is geverifieerd, genereert het autorisatie-eindpunt de juiste tokens en stuurt de browser terug naar het aanmeldingsaanroepeindpunt (/authentication/login-callback).
  • Wanneer de Blazor WebAssembly-app het callback-eindpunt voor aanmelding (/authentication/login-callback) laadt, wordt het verificatieantwoord verwerkt.
    • Als het verificatieproces is voltooid, wordt de gebruiker geverifieerd en optioneel teruggestuurd naar de oorspronkelijke beveiligde URL die de gebruiker heeft aangevraagd.
    • Als het verificatieproces om welke reden dan ook mislukt, wordt de gebruiker verzonden naar de mislukte aanmeldingspagina (/authentication/login-failed), waar een fout wordt weergegeven.

Authentication-onderdeel

Het Authentication-onderdeel (Authentication.razor) verwerkt externe verificatiebewerkingen en staat de app toe om:

  • Configureer app-routes voor verificatiestatussen.
  • Stel UI-inhoud in voor verificatiestatussen.
  • Verificatiestatus beheren.

Verificatieacties, zoals het registreren of aanmelden bij een gebruiker, worden doorgegeven aan het RemoteAuthenticatorViewCore<TAuthenticationState>-onderdeel van het Blazor framework, dat de status van verificatiebewerkingen behoudt en beheert.

Zie ASP.NET Core Blazor WebAssembly aanvullende beveiligingsscenario'svoor meer informatie en voorbeelden.

Machtiging

In Blazor WebAssembly apps kunnen autorisatiecontroles worden overgeslagen omdat alle code aan de clientzijde kan worden gewijzigd door gebruikers. Hetzelfde geldt voor alle app-technologieën aan de clientzijde, waaronder JavaScript SPA-frameworks of systeemeigen apps voor elk besturingssysteem.

Altijd autorisatiecontroles uitvoeren op de server binnen API-eindpunten die worden geopend door uw app aan de clientzijde.

Verificatie aanpassen

Blazor WebAssembly biedt methoden voor het toevoegen en ophalen van aanvullende parameters voor de onderliggende verificatiebibliotheek voor het uitvoeren van externe verificatiebewerkingen bij externe id-providers.

Als u extra parameters wilt doorgeven, biedt NavigationManager ondersteuning voor het doorgeven en ophalen van de status van de geschiedenisvermelding bij het uitvoeren van externe locatieveranderingen. Zie de volgende bronnen voor meer informatie:

De status die is opgeslagen door de Geschiedenis-API biedt de volgende voordelen voor externe verificatie:

  • De status die wordt doorgegeven aan het beveiligde app-eindpunt, is gekoppeld aan de navigatie die wordt uitgevoerd om de gebruiker te verifiëren op het authentication/login-eindpunt.
  • Extra werk bij het coderen en decoderen van gegevens wordt vermeden.
  • Beveiligingsproblemen worden verminderd. In tegenstelling tot het gebruik van de querytekenreeks om de navigatiestatus op te slaan, kan een navigatie op het hoogste niveau of invloed van een andere oorsprong de status die is opgeslagen door de Geschiedenis-API niet instellen.
  • De geschiedenisvermelding wordt vervangen na een geslaagde verificatie, dus de status die is gekoppeld aan de geschiedenisvermelding wordt verwijderd en vereist geen opschoning.

InteractiveRequestOptions vertegenwoordigt de aanvraag voor de id-provider voor het aanmelden of inrichten van een toegangstoken.

NavigationManagerExtensions biedt de NavigateToLogin methode voor een aanmeldingsbewerking en NavigateToLogout voor een afmeldingsbewerking. De methoden roepen NavigationManager.NavigateToaan, waarbij de status van de geschiedenisvermelding wordt ingesteld met een doorgegeven InteractiveRequestOptions of een nieuw InteractiveRequestOptions exemplaar dat door de methode is gecreëerd voor:

De volgende verificatiescenario's worden behandeld in het ASP.NET Core Blazor WebAssembly aanvullende beveiligingsscenario's artikel:

  • Het aanmeldingsproces aanpassen
  • Afmelden met een aangepaste retour-URL
  • Opties aanpassen voordat u een token interactief verkrijgt
  • Opties aanpassen bij het gebruik van een IAccessTokenProvider
  • Verkrijg het aanmeldingspad uit de authenticatieopties

Autorisatie vereisen voor de hele app

Pas het kenmerk [Authorize] toe (API-documentatie) op elk Razor onderdeel van de app met behulp van één van de volgende methoden:

  • Voeg in het importbestand van de app een @using-instructie toe voor de Microsoft.AspNetCore.Authorization-naamruimte, met een @attribute-instructie voor het kenmerk [Authorize].

    _Imports.razor:

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

    Anonieme toegang tot het Authentication-onderdeel toestaan om omleiding naar de id-provider toe te staan. Voeg de volgende Razor code toe aan het Authentication onderdeel onder de @page richtlijn.

    Authentication.razor:

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

  • Voeg het kenmerk toe aan elk Razor onderdeel onder de @page-instructie:

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

Notitie

Het instellen van een AuthorizationOptions.FallbackPolicy op een beleid met RequireAuthenticatedUser wordt niet ondersteund.

Gebruik één identiteitsprovider-appregistratie per app

Sommige artikelen in dit Overzicht betrekking hebben op Blazor hostingscenario's waarbij twee of meer apps betrokken zijn. Een zelfstandige Blazor WebAssembly-app maakt gebruik van web-API met geverifieerde gebruikers voor toegang tot serverbronnen en gegevens die worden geleverd door een server-app.

Wanneer dit scenario wordt geïmplementeerd in documentatievoorbeelden, worden twee registraties van id-providers gebruikt, één voor de client-app en één voor de server-app. Het gebruik van afzonderlijke registraties, bijvoorbeeld in Microsoft Entra-id, is niet strikt vereist. Het gebruik van twee registraties is echter een best practice voor beveiliging, omdat hiermee de registraties per app worden geïsoleerd. Door afzonderlijke registraties te gebruiken, kunnen ook onafhankelijke configuraties van de client- en serverregistraties worden uitgevoerd.

Enkele van de artikelen in dit Overzicht betrekking hebben op een van de volgende Blazor hostingscenario's die betrekking hebben op twee of meer apps:

  • Een gehoste Blazor WebAssembly-oplossing, die bestaat uit twee apps: een Blazor WebAssembly-app aan de clientzijde en een ASP.NET Core-host-app aan de serverzijde. Geverifieerde gebruikers voor de client-app hebben toegang tot serverbronnen en gegevens die worden geleverd door de server-app.
  • Een zelfstandige Blazor WebAssembly-app die gebruikmaakt van web-API met geverifieerde gebruikers voor toegang tot serverbronnen en gegevens die worden geleverd door een server-app. Dit scenario is vergelijkbaar met het gebruik van een gehoste Blazor WebAssembly-oplossing; maar in dit geval wordt de client-app niet gehost door de server-app.

Wanneer deze scenario's worden geïmplementeerd in documentatievoorbeelden, worden twee registraties van id-providers gebruikt, één voor de client-app en één voor de server-app. Het gebruik van afzonderlijke registraties, bijvoorbeeld in Microsoft Entra-id, is niet strikt vereist. Het gebruik van twee registraties is echter een best practice voor beveiliging, omdat hiermee de registraties per app worden geïsoleerd. Door afzonderlijke registraties te gebruiken, kunnen ook onafhankelijke configuraties van de client- en serverregistraties worden uitgevoerd.

Tokens vernieuwen

Hoewel vernieuwingstokens niet kunnen worden beveiligd in Blazor WebAssembly apps, kunnen ze worden gebruikt als u ze implementeert met de juiste beveiligingsstrategieën.

Voor zelfstandige Blazor WebAssembly-apps in ASP.NET Core in .NET 6 of hoger raden we u aan het volgende te gebruiken:

Voor gehoste Blazor WebAssembly-oplossingen kunnen vernieuwingstokens worden onderhouden en gebruikt door de app aan de serverzijde om toegang te krijgen tot API's van derden. Zie ASP.NET Core Blazor WebAssembly aanvullende beveiligingsscenario'svoor meer informatie.

Zie de volgende bronnen voor meer informatie:

Claims voor gebruikers instellen

Apps vereisen vaak claims voor gebruikers op basis van een web-API-aanroep naar een server. Claims worden bijvoorbeeld vaak gebruikt om autorisatie-in een app te tot stand te brengen. In deze scenario's vraagt de app een toegangstoken aan om toegang te krijgen tot de service en gebruikt het token om gebruikersgegevens te verkrijgen voor het maken van claims.

Zie de volgende bronnen voor voorbeelden:

Ondersteuning voor prerendering

Prerendering wordt niet ondersteund voor authenticatie-eindpunten (/authentication/ padsegment).

Prerendering wordt niet ondersteund voor authenticatie-eindpunten (/authentication/ padsegment).

Zie ASP.NET Core Blazor WebAssembly aanvullende beveiligingsscenario'svoor meer informatie.

Azure App Service in Linux met Identity Server

Geef de verlener expliciet op bij de implementatie in Azure App Service op Linux met Identity Server.

Voor meer informatie, zie Gebruik Identity om een web-API-back-end voor SPA'ste beveiligen.

Windows-verificatie

We raden u niet aan Windows-verificatie te gebruiken met Blazor WebAssembly of met een ander SPA-framework. U wordt aangeraden op tokens gebaseerde protocollen te gebruiken in plaats van Windows-verificatie, zoals OIDC met Active Directory Federation Services (ADFS).

Als Windows-verificatie wordt gebruikt met Blazor Webassembly of een ander SPA-framework, zijn er aanvullende maatregelen nodig om de app te beschermen tegen bedreigingen van cross-site request forgery (CSRF)-tokens. Dezelfde zorgen die van toepassing zijn op cookies zijn van toepassing op Windows-verificatie met de toevoeging dat Windows-verificatie geen mechanisme biedt om het delen van de verificatiecontext tussen oorsprongen te voorkomen. Apps die Gebruikmaken van Windows-verificatie zonder extra beveiliging van CSRF, moeten ten minste worden beperkt tot het intranet van een organisatie en niet worden gebruikt op het open internet.

Zie Cross-Site Request Forgery -aanvallen (XSRF/CSRF) voorkomen in ASP.NET Corevoor meer informatie.

Een SignalR-hub beveiligen

Als u een SignalR hub in het server-API-project wilt beveiligen, past u het kenmerk [Authorize] toe op de hubklasse of op methoden van de hubklasse.

In een clientproject met prerendering, zoals de gehoste Blazor WebAssembly (ASP.NET Core in .NET 7 of eerder) of een Blazor Web App (ASP.NET Core in .NET 8 of hoger), raadpleeg de richtlijnen in ASP.NET Core BlazorSignalR handleiding.

In een clientprojectcomponent zonder vooraf renderen, zoals zelfstandige componenten zoals Blazor WebAssemblyof niet-browser-apps, voorziet u een toegangstoken voor de hubverbinding, zoals het volgende voorbeeld aantoont. Zie Verificatie en autorisatie in ASP.NET Core SignalRvoor meer informatie.

@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();

  ...
}

Loggen

Deze sectie is van toepassing op Blazor WebAssembly apps in ASP.NET Core in .NET 7 of hoger.

Als u foutopsporing of traceringslogboekregistratie wilt inschakelen, raadpleegt u de sectie verificatielogboekregistratie (Blazor WebAssembly) in een 7.0- of latere versie van het ASP.NET Core Blazor-logboekregistratie artikel.

De WebAssembly-sandbox

WebAssembly sandbox- beperkt de toegang tot de omgeving van het systeem dat WebAssembly-code uitvoert, inclusief toegang tot I/O-subsystemen, systeemopslag en bronnen en het besturingssysteem. De isolatie tussen WebAssembly-code en het systeem dat de code uitvoert, maakt WebAssembly een veilig coderingsframework voor systemen. WebAssembly is echter kwetsbaar voor side-channel-aanvallen op hardwareniveau. Normale voorzorgsmaatregelen en due diligence bij hetbronnen van hardware en het plaatsen van beperkingen voor toegang tot hardware zijn van toepassing.

WebAssembly is niet eigendom van of wordt beheerd door Microsoft.

Zie de volgende W3C-resources voor meer informatie:

Implementatierichtlijnen

In dit Overzicht geven de artikelen informatie over het authenticeren van gebruikers in Blazor WebAssembly-apps voor specifieke providers.

Zelfstandige Blazor WebAssembly-apps:

Meer configuratierichtlijnen vindt u in de volgende artikelen:

De autorisatiecodestroom gebruiken met PKCE

Microsoft Identity Platform's Microsoft Authentication Library for JavaScript (MSAL) v2.0 of hoger biedt ondersteuning voor de Autorisatiecodestroom met Proof Key for Code Exchange - en CORS- (Cross-Origin Resource Sharing) voor toepassingen met één pagina, waaronder Blazor.

Microsoft raadt het gebruik van impliciete toekenning niet aan.

Zie de volgende bronnen voor meer informatie:

Aanvullende informatiebronnen