Een ASP.NET Core-Blazor Web App beveiligen met OpenID Connect (OIDC)

In dit artikel wordt beschreven hoe u een Blazor Web App beveiligt met OpenID Connect (OIDC) met behulp van een voorbeeld-app in de dotnet/blazor-samples GitHub-opslagplaats (.NET 8 of hoger) (hoe udownloadt).

In deze versie van het artikel wordt beschreven hoe u OIDC implementeert zonder het -back-endpatroon voor BFF-patroon (Back-end voor front-end) te gebruiken met een app die gebruikmaakt van globale interactieve automatische rendering (server- en .Client-projecten). Het BFF-patroon is handig voor het indienen van geverifieerde aanvragen bij externe services. Wijzig de versiekiezer van het artikel in OIDC met BFF-patroon als de specificatie van de app aanroept voor het aannemen van het BFF-patroon.

De volgende specificatie wordt behandeld:

• De Blazor Web App maakt gebruik van de automatische weergavemodus met globale interactiviteit.
• Aangepaste verificatiestatusproviderservices worden gebruikt door de server- en client-apps om de verificatiestatus van de gebruiker vast te leggen en door te stromen tussen de server en de client.
• Deze app is een startpunt voor elke OIDC-verificatiestroom. OIDC is handmatig geconfigureerd in de app en is niet afhankelijk van Microsoft Entra ID of Microsoft Identity Web-pakketten, noch vereist de voorbeeld-app Microsoft Azure hosting. De voorbeeld-app kan echter worden gebruikt met Entra, Microsoft Identity Web en gehost in Azure.
• Automatisch niet-interactief vernieuwen van tokens.
• Roept een (web)API veilig aan in het serverproject voor gegevens.

Zie voor een alternatieve ervaring met het gebruik van Microsoft Authentication Library voor .NET, Microsoft Identity Weben Microsoft Entra ID, Een ASP.NET Core Blazor Web App beveiligen met Microsoft Entra ID.

Voorbeeld-app

De voorbeeld-app bestaat uit twee projecten:

• BlazorWebAppOidc: server-kant project van de Blazor Web App, dat een voorbeeld bevat van een minimaal API--eindpunt voor weergegevens.
• BlazorWebAppOidc.Client: Project aan de clientzijde van de Blazor Web App.

Open de voorbeeld-apps via de meest recente versiemap vanuit de hoofdmap van de opslagplaats met de volgende koppeling. De projecten bevinden zich in de map BlazorWebAppOidc voor .NET 8 of hoger.

voorbeeldcode weergeven of downloaden (hoe te downloaden)

Blazor Web App project aan de serverzijde (BlazorWebAppOidc)

Het BlazorWebAppOidc project is het project aan de serverzijde van de Blazor Web App.

Het BlazorWebAppOidc.http-bestand kan worden gebruikt voor het testen van de aanvraag voor weergegevens. Houd er rekening mee dat het BlazorWebAppOidc project moet worden uitgevoerd om het eindpunt te testen en dat het eindpunt in het bestand is vastgelegd. Zie HTTP-bestanden gebruiken in Visual Studio 2022voor meer informatie.

Configuratie

In deze sectie wordt uitgelegd hoe u de voorbeeld-app configureert.

Notitie

Voor Microsoft Entra ID of Azure AD B2C kunt u AddMicrosoftIdentityWebApp gebruiken vanuit Microsoft Identity Web (Microsoft.Identity.Web NuGet-pakket, API-documentatie), waarmee zowel de OIDC- als Cookie verificatiehandlers met de juiste standaardinstellingen worden toegevoegd. De voorbeeld-app en de richtlijnen in deze sectie maken geen gebruik van Microsoft Identity Web. De richtlijnen laten zien hoe u de OIDC-handler configureert handmatig voor een OIDC-provider. Zie de gekoppelde resources voor meer informatie over het implementeren van Microsoft Identity Web.

Het clientgeheim tot stand brengen

Waarschuwing

Sla geen app-geheimen, verbindingsreeksen, referenties, wachtwoorden, persoonlijke identificatienummers (PINCODE's), persoonlijke C#/.NET-code of persoonlijke sleutels/tokens op in code aan de clientzijde. Dit is altijd onveilig. In test- en staging- en productieomgevingen moeten server-side Blazor code en web-API's veilige authenticatiestromen gebruiken om te voorkomen dat inloggegevens in projectcode of configuratiebestanden worden opgeslagen. Buiten het testen van lokale ontwikkeling raden we u aan het gebruik van omgevingsvariabelen voor het opslaan van gevoelige gegevens te vermijden, omdat omgevingsvariabelen niet de veiligste benadering zijn. Voor het testen van lokale ontwikkeling wordt het hulpprogramma Secret Manager aanbevolen voor het beveiligen van gevoelige gegevens. Zie Gevoelige gegevens en referenties veilig onderhoudenvoor meer informatie.

Voor het testen van lokale ontwikkeling gebruikt u het hulpprogramma Secret Manager om het clientgeheim van de server-app op te slaan onder de configuratiesleutel Authentication:Schemes:MicrosoftOidc:ClientSecret.

Notitie

Als de app Gebruikmaakt van Microsoft Entra ID of Azure AD B2C, maakt u een clientgeheim in de registratie van de app in de Entra- of Azure-portal (Manage>Certificates & secrets>New client secret). Gebruik de waarde van de nieuwe geheime sleutel in de volgende leidraad.

De voorbeeld-app is niet geïnitialiseerd voor het hulpprogramma Secret Manager. Gebruik een opdrachtshell, zoals de PowerShell-opdrachtshell voor ontwikkelaars in Visual Studio, om de volgende opdracht uit te voeren. Voordat u de opdracht uitvoert, wijzigt u de map met de opdracht cd in de map van het serverproject. Met de opdracht wordt een gebruikersgeheim-id (<UserSecretsId> in het projectbestand van de server-app) vastgelegd:

dotnet user-secrets init

Voer de volgende opdracht uit om het clientgeheim in te stellen. De tijdelijke aanduiding {SECRET} is het clientgeheim dat is verkregen uit de registratie van de app:

dotnet user-secrets set "Authentication:Schemes:MicrosoftOidc:ClientSecret" "{SECRET}"

Als u Visual Studio gebruikt, kunt u bevestigen dat het geheim is ingesteld door met de rechtermuisknop op het serverproject te klikken in Solution Explorer- en Gebruikersgeheimen beheren te selecteren.

De app configureren

De volgende OpenIdConnectOptions configuratie vindt u in het Program-bestand van het project bij het aanroepen van AddOpenIdConnect:

• SignInScheme: hiermee stelt u het verificatieschema in dat overeenkomt met de middleware die verantwoordelijk is voor het behouden van de identiteit van de gebruiker na een geslaagde verificatie. De OIDC-handler moet een aanmeldingsschema gebruiken dat gebruikersreferenties kan persistent maken voor alle aanvragen. De volgende regel is slechts voor demonstratiedoeleinden aanwezig. Als u dit weglaat, wordt DefaultSignInScheme gebruikt als een terugvalwaarde.

  oidcOptions.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
  

• Scopes voor openid en profile (Scope) (optioneel): De scopes openid en profile zijn standaard ook geconfigureerd omdat ze vereist zijn voor het correct functioneren van de OIDC-handler, maar deze moeten mogelijk opnieuw worden toegevoegd indien scopes in de Authentication:Schemes:MicrosoftOidc:Scope-configuratie zijn opgenomen. Zie Configuration in ASP.NET Core en ASP.NET Core Blazor configurationvoor algemene configuratierichtlijnen.

  oidcOptions.Scope.Add(OpenIdConnectScope.OpenIdProfile);
  

• SaveTokens: bepaalt of toegangs- en vernieuwingstokens na een geslaagde autorisatie moeten worden opgeslagen in de AuthenticationProperties. Deze eigenschap is ingesteld op true zodat het vernieuwingstoken wordt opgeslagen voor niet-interactieve tokenvernieuwing.

  oidcOptions.SaveTokens = true;
  

• Bereik voor offlinetoegang (Scope): De offline_access scope is vereist voor de refresh-token.

  oidcOptions.Scope.Add(OpenIdConnectScope.OfflineAccess);
  

• Authority en ClientId: hiermee stelt u de instantie- en client-id in voor OIDC-aanroepen.

  oidcOptions.Authority = "{AUTHORITY}";
  oidcOptions.ClientId = "{CLIENT ID}";
  

  Voorbeeld:

  • Instantie ({AUTHORITY}): https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/ (gebruikt Tenant-ID aaaabbbb-0000-cccc-1111-dddd2222eeee)
  • Client-id ({CLIENT ID}): 00001111-aaaa-2222-bbbb-3333cccc4444

  oidcOptions.Authority = "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/";
  oidcOptions.ClientId = "00001111-aaaa-2222-bbbb-3333cccc4444";
  

  Voorbeeld van Microsoft Azure "common" autoriteit:

  De 'algemene' autoriteit moet worden gebruikt voor multi-tenant-applicaties. U kunt ook de 'algemene' instantie voor apps met één tenant gebruiken, maar een aangepaste IssuerValidator is vereist, zoals verderop in deze sectie wordt weergegeven.

  oidcOptions.Authority = "https://login.microsoftonline.com/common/v2.0/";
  

• ResponseType: hiermee configureert u de OIDC-handler om alleen de autorisatiecodestroom uit te voeren. Impliciete toekenningen en hybride stromen zijn niet nodig in deze modus. De OIDC-handler vraagt automatisch de juiste tokens aan met behulp van de code die is geretourneerd vanaf het autorisatie-eindpunt.

  oidcOptions.ResponseType = OpenIdConnectResponseType.Code;
  

  Notitie

  Schakel in de Impliciete toekenning en hybride stromen van de Entra- of Azure-portal app-registratieconfiguratie geen selectievakje in voor het autorisatie-eindpunt om toegangstokens of id-tokenste retourneren.

• MapInboundClaims en configuratie van NameClaimType en RoleClaimType: veel OIDC-servers gebruiken "name" en "role" in plaats van de standaardinstellingen voor SOAP/WS-Fed in ClaimTypes. Wanneer MapInboundClaims is ingesteld op false, voert de handler geen claimtoewijzingen uit en worden de claimnamen van de JWT rechtstreeks door de app gebruikt. In het volgende voorbeeld wordt het type rolclaim ingesteld op 'roles'. Dit is geschikt voor Microsoft Entra-id (ME-ID). Raadpleeg de documentatie van uw id-provider voor meer informatie.

  Notitie

  MapInboundClaims moet worden ingesteld op false voor de meeste OIDC-providers, waardoor de naam van claims niet kan worden hernoemd.

  oidcOptions.MapInboundClaims = false;
  oidcOptions.TokenValidationParameters.NameClaimType = "name";
  oidcOptions.TokenValidationParameters.RoleClaimType = "roles";
  

• Padconfiguratie: de paden moeten overeenkomen met de omleidings-URI (aanmeldingscallback-pad) en het afmeldingscallback-pad die zijn geconfigureerd tijdens het registreren van de toepassing bij de OIDC-provider. In de Azure-portal worden paden geconfigureerd op de blade Verificatie van de app-registratie. Zowel de aanmeldings- als afmeldingspaden moeten worden geregistreerd als omleidings-URI's. De standaardwaarden zijn /signin-oidc en /signout-callback-oidc.

  • CallbackPath: Het verzoekpad binnen het basispad van de app waar de gebruikersagent wordt geretourneerd.

    Configureer het callbackpad na afmelding in de registratie van de OIDC-provider van de app. In het volgende voorbeeld is de tijdelijke aanduiding {PORT} de poort van de app:

    https://localhost:{PORT}/signin-oidc

    Notitie

    Een poort is niet vereist voor localhost adressen wanneer u Microsoft Entra-id gebruikt. Voor de meeste andere OIDC-providers is de juiste poort vereist.

  • nl-NL: SignedOutCallbackPath (configuratiesleutel: "SignedOutCallbackPath"): het aanvraagpad binnen het basispad van de app dat wordt onderschept door de OIDC-handler waar de gebruikersagent voor het eerst wordt geretourneerd nadat deze is uitgelogd bij de identiteitsprovider. De voorbeeld-app stelt geen waarde in voor het pad omdat de standaardwaarde van '/signout-callback-oidc' wordt gebruikt. Nadat de aanvraag is onderschept, verwijst de OIDC-handler naar de SignedOutRedirectUri of RedirectUri, indien opgegeven.

    Configureer het callbackpad na afmelding in de registratie van de OIDC-provider van de app. In het volgende voorbeeld is de tijdelijke aanduiding {PORT} de poort van de app:

    https://localhost:{PORT}/signout-callback-oidc

    Notitie

    Wanneer u Microsoft Entra-id gebruikt, stelt u het pad in de Web platformconfiguratie van de omleidings-URI in vermeldingen in de Entra- of Azure-portal. Een poort is niet vereist voor localhost adressen bij het gebruik van Entra. Voor de meeste andere OIDC-providers is de juiste poort vereist. Als u de afmeldingspad-URI niet toevoegt aan de registratie van de app in Entra, weigert Entra de gebruiker terug te leiden naar de app en vraagt hij of zij alleen hun browservenster te sluiten.

  • RemoteSignOutPath: Aanvragen die op dit pad worden ontvangen, zorgen ervoor dat de handler afmelding aanroept met behulp van het afmeldingsschema.

    In het volgende voorbeeld is de tijdelijke aanduiding {PORT} de poort van de app:

    https://localhost/signout-oidc

    Notitie

    Wanneer u Microsoft Entra ID gebruikt, stelt u de afmeldings-URL van het Front-channel in in de Entra- of Azure-portal. Een poort is niet vereist voor localhost adressen bij het gebruik van Entra. Voor de meeste andere OIDC-providers is de juiste poort vereist.

    oidcOptions.CallbackPath = new PathString("{PATH}");
    oidcOptions.SignedOutCallbackPath = new PathString("{PATH}");
    oidcOptions.RemoteSignOutPath = new PathString("{PATH}");
    

    Voorbeelden (standaardwaarden):

    oidcOptions.CallbackPath = new PathString("/signin-oidc");
    oidcOptions.SignedOutCallbackPath = new PathString("/signout-callback-oidc");
    oidcOptions.RemoteSignOutPath = new PathString("/signout-oidc");
    

• (Microsoft Azure alleen met het 'algemene' eindpunt) TokenValidationParameters.IssuerValidator: veel OIDC-providers werken met de standaardvalidator voor issuers, maar we moeten rekening houden met de issuer die is geparameteriseerd met de tenant-id ({TENANT ID}) die door https://login.microsoftonline.com/common/v2.0/.well-known/openid-configurationwordt geretourneerd. Voor meer informatie, zie SecurityTokenInvalidIssuerException met OpenID Connect en het Azure AD "common" eindpunt (AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet #1731).

  Alleen voor apps die Gebruikmaken van Microsoft Entra ID of Azure AD B2C met het 'algemene' eindpunt:

  var microsoftIssuerValidator = AadIssuerValidator.GetAadIssuerValidator(oidcOptions.Authority);
  oidcOptions.TokenValidationParameters.IssuerValidator = microsoftIssuerValidator.Validate;
  

Voorbeeld-app-code

Inspecteer de voorbeeld-app voor de volgende functies:

• Automatische niet-interactieve tokenvernieuwing met een aangepaste cookie opfrisser (CookieOidcRefresher.cs).
• Het serverproject roept AddAuthenticationStateSerialization aan om een verificatiestatusprovider aan de serverzijde toe te voegen die gebruikmaakt van PersistentComponentState om de verificatiestatus naar de client te laten stromen. De client roept AddAuthenticationStateDeserialization aan om te deserialiseren en de authenticatiestatus te gebruiken, zoals door de server doorgegeven. De verificatiestatus is vast voor de levensduur van de WebAssembly-toepassing.
• Een voorbeeld van aanvragen voor de Blazor Web App voor weergegevens wordt verwerkt door een minimaal API-eindpunt (/weather-forecast) in het Program-bestand (Program.cs). Voor het eindpunt is autorisatie vereist door RequireAuthorizationaan te roepen. Voor controllers die u aan het project toevoegt, voegt u het kenmerk [Authorize] toe aan de controller of actie. Zie de Razorvoor meer informatie over het vereisen van autorisatie in de hele app via een autorisatiebeleid en het uitzonderen van autorisatie bij een subset van openbare eindpunten.
• De app roept een (web)API veilig aan in het serverproject voor weergegevens:
  • Wanneer het Weather onderdeel op de server wordt weergegeven, gebruikt het onderdeel de ServerWeatherForecaster op de server om rechtstreeks weergegevens te verkrijgen (niet via een web-API-aanroep).
  • Wanneer het onderdeel wordt weergegeven op de client, gebruikt het onderdeel de ClientWeatherForecaster-service-implementatie, die gebruikmaakt van een vooraf geconfigureerde HttpClient (in het Program-bestand van het clientproject) om een web-API-aanroep naar het serverproject uit te voeren. Een minimaal API-eindpunt (/weather-forecast) dat is gedefinieerd in het Program-bestand van het serverproject, haalt de weergegevens op uit de ServerWeatherForecaster en retourneert de gegevens naar de client.

Voor meer informatie over (web)API-aanroepen met behulp van serviceabstracties in Blazor Web App's, zie Een web-API aanroepen vanuit een ASP.NET Core Blazor-app.

Blazor Web App project aan de clientzijde (BlazorWebAppOidc.Client)

Het BlazorWebAppOidc.Client project is het project aan de clientzijde van de Blazor Web App.

De client roept AddAuthenticationStateDeserialization aan om te deserialiseren en de authenticatiestatus te gebruiken, zoals door de server doorgegeven. De verificatiestatus is vast voor de levensduur van de WebAssembly-toepassing.

Als de gebruiker zich moet aanmelden of afmelden, is een volledige pagina opnieuw laden vereist.

De voorbeeld-app biedt alleen een gebruikersnaam en e-mail voor weergavedoeleinden. Het bevat geen tokens die worden geverifieerd bij de server bij het maken van volgende aanvragen, wat afzonderlijk werkt met behulp van een cookie die is opgenomen in HttpClient aanvragen naar de server.

In deze versie van het artikel wordt beschreven hoe u OIDC implementeert zonder het patroon Backend for Frontend (BFF) te gebruiken met een app die gebruikmaakt van globale Interactive Server-rendering (één project). Het BFF-patroon is handig voor het indienen van geverifieerde aanvragen bij externe services. Wijzig de artikelversiekiezer in OIDC met BFF-patroon als de specificatie van de app vereist dat het BFF-patroon met globale interactieve automatische rendering wordt aangenomen.

De volgende specificatie wordt behandeld:

• De Blazor Web App gebruikt de serverweergavemodus met globale interactiviteit.
• Deze app is een startpunt voor elke OIDC-verificatiestroom. OIDC is handmatig geconfigureerd in de app en is niet afhankelijk van Microsoft Entra ID of Microsoft Identity Web-pakketten, noch vereist de voorbeeld-app Microsoft Azure hosting. De voorbeeld-app kan echter worden gebruikt met Entra, Microsoft Identity Web en gehost in Azure.
• Automatisch niet-interactief vernieuwen van tokens.

Zie voor een alternatieve ervaring met het gebruik van Microsoft Authentication Library voor .NET, Microsoft Identity Weben Microsoft Entra ID, Een ASP.NET Core Blazor Web App beveiligen met Microsoft Entra ID.

Voorbeeld-app

De voorbeeldapplicatie bestaat uit één server-side Blazor Web App-project (BlazorWebAppOidcServer).

Toegang krijgen tot de voorbeeld-app via de laatste versie map vanuit de hoofdmap van de repository met de volgende link. Het project bevindt zich in de map BlazorWebAppOidcServer voor .NET 8 of hoger.

voorbeeldcode weergeven of downloaden (hoe te downloaden)

Configuratie

In deze sectie wordt uitgelegd hoe u de voorbeeld-app configureert.

Notitie

Voor Microsoft Entra ID of Azure AD B2C kunt u AddMicrosoftIdentityWebApp gebruiken vanuit Microsoft Identity Web (Microsoft.Identity.Web NuGet-pakket, API-documentatie), waarmee zowel de OIDC- als Cookie verificatiehandlers met de juiste standaardinstellingen worden toegevoegd. De voorbeeld-app en de richtlijnen in deze sectie maken geen gebruik van Microsoft Identity Web. De richtlijnen laten zien hoe u de OIDC-handler configureert handmatig voor een OIDC-provider. Zie de gekoppelde resources voor meer informatie over het implementeren van Microsoft Identity Web.

Het clientgeheim tot stand brengen

Waarschuwing

Sla geen app-geheimen, verbindingsreeksen, referenties, wachtwoorden, persoonlijke identificatienummers (PINCODE's), persoonlijke C#/.NET-code of persoonlijke sleutels/tokens op in code aan de clientzijde. Dit is altijd onveilig. In test- en staging- en productieomgevingen moeten server-side Blazor code en web-API's veilige authenticatiestromen gebruiken om te voorkomen dat inloggegevens in projectcode of configuratiebestanden worden opgeslagen. Buiten het testen van lokale ontwikkeling raden we u aan het gebruik van omgevingsvariabelen voor het opslaan van gevoelige gegevens te vermijden, omdat omgevingsvariabelen niet de veiligste benadering zijn. Voor het testen van lokale ontwikkeling wordt het hulpprogramma Secret Manager aanbevolen voor het beveiligen van gevoelige gegevens. Zie Gevoelige gegevens en referenties veilig onderhoudenvoor meer informatie.

Voor het testen van lokale ontwikkeling gebruikt u het hulpprogramma Secret Manager om het clientgeheim van de app op te slaan onder de configuratiesleutel Authentication:Schemes:MicrosoftOidc:ClientSecret.

Notitie

Als de app Gebruikmaakt van Microsoft Entra ID of Azure AD B2C, maakt u een clientgeheim in de registratie van de app in de Entra- of Azure-portal (Manage>Certificates & secrets>New client secret). Gebruik de waarde van de nieuwe geheime sleutel in de volgende leidraad.

De voorbeeld-app is niet geïnitialiseerd voor het hulpprogramma Secret Manager. Gebruik een opdrachtshell, zoals de PowerShell-opdrachtshell voor ontwikkelaars in Visual Studio, om de volgende opdracht uit te voeren. Voordat u de opdracht uitvoert, wijzigt u de map met de opdracht cd in de map van het project. Met de opdracht wordt een gebruikersgeheim-id (<UserSecretsId> in het projectbestand van de app) vastgelegd:

dotnet user-secrets init

Voer de volgende opdracht uit om het clientgeheim in te stellen. De tijdelijke aanduiding {SECRET} is het clientgeheim dat is verkregen uit de registratie van de app:

dotnet user-secrets set "Authentication:Schemes:MicrosoftOidc:ClientSecret" "{SECRET}"

Als u Visual Studio gebruikt, kunt u bevestigen dat het geheim is ingesteld door met de rechtermuisknop op het project te klikken in Solution Explorer- en Gebruikersgeheimen beheren te selecteren.

De app configureren

De volgende OpenIdConnectOptions configuratie vindt u in het Program-bestand van het project bij het aanroepen van AddOpenIdConnect:

• SignInScheme: hiermee stelt u het verificatieschema in dat overeenkomt met de middleware die verantwoordelijk is voor het behouden van de identiteit van de gebruiker na een geslaagde verificatie. De OIDC-handler moet een aanmeldingsschema gebruiken dat gebruikersreferenties kan persistent maken voor alle aanvragen. De volgende regel is slechts voor demonstratiedoeleinden aanwezig. Als u dit weglaat, wordt DefaultSignInScheme gebruikt als een terugvalwaarde.

  oidcOptions.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
  

• Scopes voor openid en profile (Scope) (optioneel): De scopes openid en profile zijn standaard ook geconfigureerd omdat ze vereist zijn voor het correct functioneren van de OIDC-handler, maar deze moeten mogelijk opnieuw worden toegevoegd indien scopes in de Authentication:Schemes:MicrosoftOidc:Scope-configuratie zijn opgenomen. Zie Configuration in ASP.NET Core en ASP.NET Core Blazor configurationvoor algemene configuratierichtlijnen.

  oidcOptions.Scope.Add(OpenIdConnectScope.OpenIdProfile);
  

• SaveTokens: bepaalt of toegangs- en vernieuwingstokens na een geslaagde autorisatie moeten worden opgeslagen in de AuthenticationProperties. Deze eigenschap is ingesteld op true zodat het vernieuwingstoken wordt opgeslagen voor niet-interactieve tokenvernieuwing.

  oidcOptions.SaveTokens = true;
  
  

• Bereik voor offlinetoegang (Scope): De offline_access scope is vereist voor de refresh-token.

  oidcOptions.Scope.Add(OpenIdConnectScope.OfflineAccess);
  

• Authority en ClientId: hiermee stelt u de instantie- en client-id in voor OIDC-aanroepen.

  oidcOptions.Authority = "{AUTHORITY}";
  oidcOptions.ClientId = "{CLIENT ID}";
  

  Voorbeeld:

  • Instantie ({AUTHORITY}): https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/ (gebruikt Tenant-ID aaaabbbb-0000-cccc-1111-dddd2222eeee)
  • Client-id ({CLIENT ID}): 00001111-aaaa-2222-bbbb-3333cccc4444

  oidcOptions.Authority = "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/";
  oidcOptions.ClientId = "00001111-aaaa-2222-bbbb-3333cccc4444";
  

  Voorbeeld van Microsoft Azure "common" autoriteit:

  De 'algemene' autoriteit moet worden gebruikt voor multi-tenant-applicaties. U kunt ook de 'algemene' instantie voor apps met één tenant gebruiken, maar een aangepaste IssuerValidator is vereist, zoals verderop in deze sectie wordt weergegeven.

  oidcOptions.Authority = "https://login.microsoftonline.com/common/v2.0/";
  

• ResponseType: hiermee configureert u de OIDC-handler om alleen de autorisatiecodestroom uit te voeren. Impliciete toekenningen en hybride stromen zijn niet nodig in deze modus. De OIDC-handler vraagt automatisch de juiste tokens aan met behulp van de code die is geretourneerd vanaf het autorisatie-eindpunt.

  oidcOptions.ResponseType = OpenIdConnectResponseType.Code;
  

  Notitie

  Schakel in de Impliciete toekenning en hybride stromen van de Entra- of Azure-portal app-registratieconfiguratie geen selectievakje in voor het autorisatie-eindpunt om toegangstokens of id-tokenste retourneren.

• MapInboundClaims en configuratie van NameClaimType en RoleClaimType: veel OIDC-servers gebruiken "name" en "role" in plaats van de standaardinstellingen voor SOAP/WS-Fed in ClaimTypes. Wanneer MapInboundClaims is ingesteld op false, voert de handler geen claimtoewijzingen uit en worden de claimnamen van de JWT rechtstreeks door de app gebruikt. In het volgende voorbeeld wordt het type rolclaim ingesteld op 'roles'. Dit is geschikt voor Microsoft Entra-id (ME-ID). Raadpleeg de documentatie van uw id-provider voor meer informatie.

  Notitie

  MapInboundClaims moet worden ingesteld op false voor de meeste OIDC-providers, waardoor de naam van claims niet kan worden hernoemd.

  oidcOptions.MapInboundClaims = false;
  oidcOptions.TokenValidationParameters.NameClaimType = "name";
  oidcOptions.TokenValidationParameters.RoleClaimType = "roles";
  

• Padconfiguratie: de paden moeten overeenkomen met de omleidings-URI (aanmeldingscallback-pad) en het afmeldingscallback-pad die zijn geconfigureerd tijdens het registreren van de toepassing bij de OIDC-provider. In de Azure-portal worden paden geconfigureerd op de blade Verificatie van de app-registratie. Zowel de aanmeldings- als afmeldingspaden moeten worden geregistreerd als omleidings-URI's. De standaardwaarden zijn /signin-oidc en /signout-callback-oidc.

  • CallbackPath: Het verzoekpad binnen het basispad van de app waar de gebruikersagent wordt geretourneerd.

    Configureer het callbackpad na afmelding in de registratie van de OIDC-provider van de app. In het volgende voorbeeld is de tijdelijke aanduiding {PORT} de poort van de app:

    https://localhost:{PORT}/signin-oidc

    Notitie

    Een poort is niet vereist voor localhost adressen wanneer u Microsoft Entra-id gebruikt. Voor de meeste andere OIDC-providers is de juiste poort vereist.

  • nl-NL: SignedOutCallbackPath (configuratiesleutel: "SignedOutCallbackPath"): het aanvraagpad binnen het basispad van de app dat wordt onderschept door de OIDC-handler waar de gebruikersagent voor het eerst wordt geretourneerd nadat deze is uitgelogd bij de identiteitsprovider. De voorbeeld-app stelt geen waarde in voor het pad omdat de standaardwaarde van '/signout-callback-oidc' wordt gebruikt. Nadat de aanvraag is onderschept, verwijst de OIDC-handler naar de SignedOutRedirectUri of RedirectUri, indien opgegeven.

    Configureer het callbackpad na afmelding in de registratie van de OIDC-provider van de app. In het volgende voorbeeld is de tijdelijke aanduiding {PORT} de poort van de app:

    https://localhost:{PORT}/signout-callback-oidc

    Notitie

    Wanneer u Microsoft Entra-id gebruikt, stelt u het pad in de Web platformconfiguratie van de omleidings-URI in vermeldingen in de Entra- of Azure-portal. Een poort is niet vereist voor localhost adressen bij het gebruik van Entra. Voor de meeste andere OIDC-providers is de juiste poort vereist. Als u de afmeldingspad-URI niet toevoegt aan de registratie van de app in Entra, weigert Entra de gebruiker terug te leiden naar de app en vraagt hij of zij alleen hun browservenster te sluiten.

  • RemoteSignOutPath: Aanvragen die op dit pad worden ontvangen, zorgen ervoor dat de handler afmelding aanroept met behulp van het afmeldingsschema.

    In het volgende voorbeeld is de tijdelijke aanduiding {PORT} de poort van de app:

    https://localhost/signout-oidc

    Notitie

    Wanneer u Microsoft Entra ID gebruikt, stelt u de afmeldings-URL van het Front-channel in in de Entra- of Azure-portal. Een poort is niet vereist voor localhost adressen bij het gebruik van Entra. Voor de meeste andere OIDC-providers is de juiste poort vereist.

    oidcOptions.CallbackPath = new PathString("{PATH}");
    oidcOptions.SignedOutCallbackPath = new PathString("{PATH}");
    oidcOptions.RemoteSignOutPath = new PathString("{PATH}");
    

    Voorbeelden (standaardwaarden):

    oidcOptions.CallbackPath = new PathString("/signin-oidc");
    oidcOptions.SignedOutCallbackPath = new PathString("/signout-callback-oidc");
    oidcOptions.RemoteSignOutPath = new PathString("/signout-oidc");
    

• (Microsoft Azure alleen met het 'algemene' eindpunt) TokenValidationParameters.IssuerValidator: veel OIDC-providers werken met de standaardvalidator voor issuers, maar we moeten rekening houden met de issuer die is geparameteriseerd met de tenant-id ({TENANT ID}) die door https://login.microsoftonline.com/common/v2.0/.well-known/openid-configurationwordt geretourneerd. Voor meer informatie, zie SecurityTokenInvalidIssuerException met OpenID Connect en het Azure AD "common" eindpunt (AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet #1731).

  Alleen voor apps die Gebruikmaken van Microsoft Entra ID of Azure AD B2C met het 'algemene' eindpunt:

  var microsoftIssuerValidator = AadIssuerValidator.GetAadIssuerValidator(oidcOptions.Authority);
  oidcOptions.TokenValidationParameters.IssuerValidator = microsoftIssuerValidator.Validate;
  

Voorbeeld-app-code

Inspecteer de voorbeeld-app voor de volgende functies:

• Automatische niet-interactieve tokenvernieuwing met een aangepaste cookie opfrisser (CookieOidcRefresher.cs).
• Het Weather-onderdeel maakt gebruik van het [Authorize] kenmerk om onbevoegde toegang te voorkomen. Zie de Razorvoor meer informatie over het vereisen van autorisatie in de hele app via een autorisatiebeleid en het uitzonderen van autorisatie bij een subset van openbare eindpunten.

In deze versie van het artikel wordt uitgelegd hoe u OIDC implementeert met het Backend-voor-Frontend (BFF) patroon . Wijzig de versiekiezer van het artikel in OIDC zonder BFF-patroon als de specificatie van de app niet aanroept om het BFF-patroon te gebruiken.

De volgende specificatie wordt behandeld:

• De Blazor Web App maakt gebruik van de automatische weergavemodus met globale interactiviteit.
• Aangepaste verificatiestatusproviderservices worden gebruikt door de server- en client-apps om de verificatiestatus van de gebruiker vast te leggen en door te stromen tussen de server en de client.
• Deze app is een startpunt voor elke OIDC-verificatiestroom. OIDC is handmatig geconfigureerd in de app en is niet afhankelijk van Microsoft Entra ID of Microsoft Identity Web-pakketten, noch vereist de voorbeeld-app Microsoft Azure hosting. De voorbeeld-app kan echter worden gebruikt met Entra, Microsoft Identity Web en gehost in Azure.
• Automatisch niet-interactief vernieuwen van tokens.
• Het BFF-patroon (Backend for Frontend) wordt gebruikt met behulp van .NET Aspire voor servicedetectie en YARP- voor het proxyen van aanvragen naar een weersvoorspellingseindpunt in de back-end-app.
  • Een back-end web-API maakt gebruik van JWT-bearer-verificatie om JWT-tokens te valideren die zijn opgeslagen door de Blazor Web App bij de aanmelding cookie.
  • Aspire verbetert de ervaring bij het bouwen van cloud-native .NET-apps. Het biedt een consistente, uitgesproken set tools en patronen voor het bouwen en uitvoeren van gedistribueerde apps.
  • YARP (Yet Another Reverse Proxy) is een bibliotheek die wordt gebruikt om een omgekeerde proxyserver te maken.

Zie voor meer informatie over .NET Aspire: Algemene Beschikbaarheid van .NET Aspire: de vereenvoudiging van .NET Cloud-Native-ontwikkeling (mei 2024).

Voorwaarde

.NET Aspire vereist Visual Studio versie 17.10 of hoger.

Voorbeeld-app

De voorbeeld-app bestaat uit vijf projecten:

• .NET Aspire:
  • Aspire.AppHost: wordt gebruikt voor het beheren van de orkestratie op hoog niveau van de app.
  • Aspire.ServiceDefaults: bevat standaard-.NET Aspire app-configuraties die naar behoefte kunnen worden uitgebreid en aangepast.
• MinimalApiJwt: Backend-web-API dat een voorbeeld bevat van een Minimale API eindpunt voor weergegevens.
• BlazorWebAppOidc: serverside project van het Blazor Web App.
• BlazorWebAppOidc.Client: Project aan de clientzijde van de Blazor Web App.

Open de voorbeeld-apps via de meest recente versiemap vanuit de hoofdmap van de opslagplaats met de volgende koppeling. De projecten bevinden zich in de map BlazorWebAppOidcBff voor .NET 8 of hoger.

voorbeeldcode weergeven of downloaden (hoe te downloaden)

.NET Aspire projecten

Zie de .NET Aspirevoor meer informatie over het gebruik van .AppHost en details over de .ServiceDefaults en .NET Aspire projecten van de voorbeeld-app.

Controleer of u aan de vereisten voor .NET Aspirehebt voldaan. Zie de sectie Vereisten van Quickstart: Uw eerste .NET Aspire-app bouwenvoor meer informatie.

De voorbeeld-app configureert alleen een onveilig HTTP-startprofiel (http) voor gebruik tijdens het testen van de ontwikkeling. Voor meer informatie, waaronder een voorbeeld van onveilige en beveiligde startinstellingen-profielen, zie Onbeveiligd transport toestaan in .NET Aspire (.NET Aspire documentatie).

Blazor Web App project aan de serverzijde (BlazorWebAppOidc)

Het BlazorWebAppOidc project is het project aan de serverzijde van de Blazor Web App. Het project maakt gebruik van YARP- om proxy-aanvragen naar een weersvoorspellingseindpunt in het back-end-web-API-project (MinimalApiJwt) mogelijk te maken, met de access_token opgeslagen in de authenticatie-cookie.

Het BlazorWebAppOidc.http-bestand kan worden gebruikt voor het testen van de aanvraag voor weergegevens. Houd er rekening mee dat het BlazorWebAppOidc project moet worden uitgevoerd om het eindpunt te testen en dat het eindpunt in het bestand is vastgelegd. Zie HTTP-bestanden gebruiken in Visual Studio 2022voor meer informatie.

Configuratie

In deze sectie wordt uitgelegd hoe u de voorbeeld-app configureert.

Notitie

Voor Microsoft Entra ID of Azure AD B2C kunt u AddMicrosoftIdentityWebApp gebruiken vanuit Microsoft Identity Web (Microsoft.Identity.Web NuGet-pakket, API-documentatie), waarmee zowel de OIDC- als Cookie verificatiehandlers met de juiste standaardinstellingen worden toegevoegd. De voorbeeld-app en de richtlijnen in deze sectie maken geen gebruik van Microsoft Identity Web. De richtlijnen laten zien hoe u de OIDC-handler configureert handmatig voor een OIDC-provider. Zie de gekoppelde resources voor meer informatie over het implementeren van Microsoft Identity Web.

Het clientgeheim tot stand brengen

Waarschuwing

Sla geen app-geheimen, verbindingsreeksen, referenties, wachtwoorden, persoonlijke identificatienummers (PINCODE's), persoonlijke C#/.NET-code of persoonlijke sleutels/tokens op in code aan de clientzijde. Dit is altijd onveilig. In test- en staging- en productieomgevingen moeten server-side Blazor code en web-API's veilige authenticatiestromen gebruiken om te voorkomen dat inloggegevens in projectcode of configuratiebestanden worden opgeslagen. Buiten het testen van lokale ontwikkeling raden we u aan het gebruik van omgevingsvariabelen voor het opslaan van gevoelige gegevens te vermijden, omdat omgevingsvariabelen niet de veiligste benadering zijn. Voor het testen van lokale ontwikkeling wordt het hulpprogramma Secret Manager aanbevolen voor het beveiligen van gevoelige gegevens. Zie Gevoelige gegevens en referenties veilig onderhoudenvoor meer informatie.

Voor het testen van lokale ontwikkeling gebruikt u het hulpprogramma Secret Manager om het clientgeheim van de server-app op te slaan onder de configuratiesleutel Authentication:Schemes:MicrosoftOidc:ClientSecret.

Notitie

Als de app Gebruikmaakt van Microsoft Entra ID of Azure AD B2C, maakt u een clientgeheim in de registratie van de app in de Entra- of Azure-portal (Manage>Certificates & secrets>New client secret). Gebruik de waarde van de nieuwe geheime sleutel in de volgende leidraad.

De voorbeeld-app is niet geïnitialiseerd voor het hulpprogramma Secret Manager. Gebruik een opdrachtshell, zoals de PowerShell-opdrachtshell voor ontwikkelaars in Visual Studio, om de volgende opdracht uit te voeren. Voordat u de opdracht uitvoert, wijzigt u de map met de opdracht cd in de map van het serverproject. Met de opdracht wordt een gebruikersgeheim-id (<UserSecretsId> in het projectbestand van de server-app) vastgelegd:

dotnet user-secrets init

Voer de volgende opdracht uit om het clientgeheim in te stellen. De tijdelijke aanduiding {SECRET} is het clientgeheim dat is verkregen uit de registratie van de app:

dotnet user-secrets set "Authentication:Schemes:MicrosoftOidc:ClientSecret" "{SECRET}"

Als u Visual Studio gebruikt, kunt u bevestigen dat het geheim is ingesteld door met de rechtermuisknop op het serverproject te klikken in Solution Explorer- en Gebruikersgeheimen beheren te selecteren.

De app configureren

De volgende OpenIdConnectOptions configuratie vindt u in het Program-bestand van het project bij het aanroepen van AddOpenIdConnect:

• SignInScheme: hiermee stelt u het verificatieschema in dat overeenkomt met de middleware die verantwoordelijk is voor het behouden van de identiteit van de gebruiker na een geslaagde verificatie. De OIDC-handler moet een aanmeldingsschema gebruiken dat gebruikersreferenties kan persistent maken voor alle aanvragen. De volgende regel is slechts voor demonstratiedoeleinden aanwezig. Als u dit weglaat, wordt DefaultSignInScheme gebruikt als een terugvalwaarde.

  oidcOptions.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
  

• Scopes voor openid en profile (Scope) (optioneel): De scopes openid en profile zijn standaard ook geconfigureerd omdat ze vereist zijn voor het correct functioneren van de OIDC-handler, maar deze moeten mogelijk opnieuw worden toegevoegd indien scopes in de Authentication:Schemes:MicrosoftOidc:Scope-configuratie zijn opgenomen. Zie Configuration in ASP.NET Core en ASP.NET Core Blazor configurationvoor algemene configuratierichtlijnen.

  oidcOptions.Scope.Add(OpenIdConnectScope.OpenIdProfile);
  

• SaveTokens: bepaalt of toegangs- en vernieuwingstokens na een geslaagde autorisatie moeten worden opgeslagen in de AuthenticationProperties. De waarde is ingesteld op true voor het verifiëren van aanvragen voor weergegevens van het back-end-web-API-project (MinimalApiJwt).

  oidcOptions.SaveTokens = true;
  

• Bereik voor offlinetoegang (Scope): De offline_access scope is vereist voor de refresh-token.

  oidcOptions.Scope.Add(OpenIdConnectScope.OfflineAccess);
  

• Bereiken voor het verkrijgen van weergegevens van de web-API (Scope): Dit is nodig voor het back-end-web-API-project (MinimalApiJwt) om het toegangstoken te valideren met bearer JWT.

  oidcOptions.Scope.Add("{APP ID URI}/{API NAME}");
  

  Notitie

  Wanneer u Microsoft Entra ID gebruikt, wordt het Weather.Get-bereik geconfigureerd in de Azure- of Entra-portal onder Een APIbeschikbaar maken.

  Voorbeeld:

  • App-id-URI ({APP ID URI}): https://{DIRECTORY NAME}.onmicrosoft.com/{CLIENT ID}
    • Mapnaam ({DIRECTORY NAME}): contoso
    • Applicatie-id (cliënt) ({CLIENT ID}): 00001111-aaaa-2222-bbbb-3333cccc4444
  • Bereik geconfigureerd voor weergegevens uit MinimalApiJwt ({API NAME}): Weather.Get

  oidcOptions.Scope.Add("https://contoso.onmicrosoft.com/00001111-aaaa-2222-bbbb-3333cccc4444/Weather.Get");
  

  Het voorgaande voorbeeld heeft betrekking op een app die is geregistreerd in een tenant met een AAD B2C-tenanttype. Als de app is geregistreerd in een ME-ID tenant, is de URI van de app-id anders, dus het bereik is anders.

  Voorbeeld:

  • App-id-URI ({APP ID URI}): api://{CLIENT ID} met toepassings-id ({CLIENT ID}): 00001111-aaaa-2222-bbbb-3333cccc4444
  • Bereik geconfigureerd voor weergegevens uit MinimalApiJwt ({API NAME}): Weather.Get

  oidcOptions.Scope.Add("api://00001111-aaaa-2222-bbbb-3333cccc4444/Weather.Get");
  

• Authority en ClientId: hiermee stelt u de instantie- en client-id in voor OIDC-aanroepen.

  oidcOptions.Authority = "{AUTHORITY}";
  oidcOptions.ClientId = "{CLIENT ID}";
  

  Voorbeeld:

  • Instantie ({AUTHORITY}): https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/ (gebruikt Tenant-ID aaaabbbb-0000-cccc-1111-dddd2222eeee)
  • Client-id ({CLIENT ID}): 00001111-aaaa-2222-bbbb-3333cccc4444

  oidcOptions.Authority = "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/";
  oidcOptions.ClientId = "00001111-aaaa-2222-bbbb-3333cccc4444";
  

  Voorbeeld van Microsoft Azure "common" autoriteit:

  De 'algemene' autoriteit moet worden gebruikt voor multi-tenant-applicaties. U kunt ook de 'algemene' instantie voor apps met één tenant gebruiken, maar een aangepaste IssuerValidator is vereist, zoals verderop in deze sectie wordt weergegeven.

  oidcOptions.Authority = "https://login.microsoftonline.com/common/v2.0/";
  

• ResponseType: hiermee configureert u de OIDC-handler om alleen de autorisatiecodestroom uit te voeren. Impliciete toekenningen en hybride stromen zijn niet nodig in deze modus. De OIDC-handler vraagt automatisch de juiste tokens aan met behulp van de code die is geretourneerd vanaf het autorisatie-eindpunt.

  oidcOptions.ResponseType = OpenIdConnectResponseType.Code;
  

  Notitie

  Wanneer u Microsoft Entra-id gebruikt, schakelt u niet selectievakje in voor het autorisatie-eindpunt om toegangstokens of id-tokens te retourneren in Impliciete toekenning en hybride stromen app-registratieconfiguratie.

• MapInboundClaims en configuratie van NameClaimType en RoleClaimType: veel OIDC-servers gebruiken "name" en "role" in plaats van de standaardinstellingen voor SOAP/WS-Fed in ClaimTypes. Wanneer MapInboundClaims is ingesteld op false, voert de handler geen claimtoewijzingen uit en worden de claimnamen van de JWT rechtstreeks door de app gebruikt. In het volgende voorbeeld wordt het type rolclaim ingesteld op 'roles'. Dit is geschikt voor Microsoft Entra-id (ME-ID). Raadpleeg de documentatie van uw id-provider voor meer informatie.

  Notitie

  MapInboundClaims moet worden ingesteld op false voor de meeste OIDC-providers, waardoor de naam van claims niet kan worden hernoemd.

  oidcOptions.MapInboundClaims = false;
  oidcOptions.TokenValidationParameters.NameClaimType = "name";
  oidcOptions.TokenValidationParameters.RoleClaimType = "roles";
  

• Padconfiguratie: de paden moeten overeenkomen met de omleidings-URI (aanmeldingscallback-pad) en het afmeldingscallback-pad die zijn geconfigureerd tijdens het registreren van de toepassing bij de OIDC-provider. In de Azure-portal worden paden geconfigureerd op de blade Verificatie van de app-registratie. Zowel de aanmeldings- als afmeldingspaden moeten worden geregistreerd als omleidings-URI's. De standaardwaarden zijn /signin-oidc en /signout-callback-oidc.

  Configureer het callbackpad na afmelding in de registratie van de OIDC-provider van de app. In het volgende voorbeeld is de tijdelijke aanduiding {PORT} de poort van de app:

  https://localhost:{PORT}/signin-oidc

  Notitie

  Een poort is niet vereist voor localhost adressen wanneer u Microsoft Entra-id gebruikt. Voor de meeste andere OIDC-providers is de juiste poort vereist.

  • nl-NL: SignedOutCallbackPath (configuratiesleutel: "SignedOutCallbackPath"): het aanvraagpad binnen het basispad van de app dat wordt onderschept door de OIDC-handler waar de gebruikersagent voor het eerst wordt geretourneerd nadat deze is uitgelogd bij de identiteitsprovider. De voorbeeld-app stelt geen waarde in voor het pad omdat de standaardwaarde van '/signout-callback-oidc' wordt gebruikt. Nadat de aanvraag is onderschept, verwijst de OIDC-handler naar de SignedOutRedirectUri of RedirectUri, indien opgegeven.

    Configureer het callbackpad na afmelding in de registratie van de OIDC-provider van de app. In het volgende voorbeeld is de tijdelijke aanduiding {PORT} de poort van de app:

    https://localhost:{PORT}/signout-callback-oidc

    Notitie

    Wanneer u Microsoft Entra-id gebruikt, stelt u het pad in de Web platformconfiguratie van de omleidings-URI in vermeldingen in de Entra- of Azure-portal. Een poort is niet vereist voor localhost adressen bij het gebruik van Entra. Voor de meeste andere OIDC-providers is de juiste poort vereist. Als u de afmeldingspad-URI niet toevoegt aan de registratie van de app in Entra, weigert Entra de gebruiker terug te leiden naar de app en vraagt hij of zij alleen hun browservenster te sluiten.

  • RemoteSignOutPath: Aanvragen die op dit pad worden ontvangen, zorgen ervoor dat de handler afmelding aanroept met behulp van het afmeldingsschema.

    In het volgende voorbeeld is de tijdelijke aanduiding {PORT} de poort van de app:

    https://localhost/signout-oidc

    Notitie

    Wanneer u Microsoft Entra ID gebruikt, stelt u de afmeldings-URL van het Front-channel in in de Entra- of Azure-portal. Een poort is niet vereist voor localhost adressen bij het gebruik van Entra. Voor de meeste andere OIDC-providers is de juiste poort vereist.

    oidcOptions.CallbackPath = new PathString("{PATH}");
    oidcOptions.SignedOutCallbackPath = new PathString("{PATH}");
    oidcOptions.RemoteSignOutPath = new PathString("{PATH}");
    

    Voorbeelden (standaardwaarden):

    oidcOptions.CallbackPath = new PathString("/signin-oidc");
    oidcOptions.SignedOutCallbackPath = new PathString("/signout-callback-oidc");
    oidcOptions.RemoteSignOutPath = new PathString("/signout-oidc");
    

• (Microsoft Azure alleen met het 'algemene' eindpunt) TokenValidationParameters.IssuerValidator: veel OIDC-providers werken met de standaardvalidator voor issuers, maar we moeten rekening houden met de issuer die is geparameteriseerd met de tenant-id ({TENANT ID}) die door https://login.microsoftonline.com/common/v2.0/.well-known/openid-configurationwordt geretourneerd. Voor meer informatie, zie SecurityTokenInvalidIssuerException met OpenID Connect en het Azure AD "common" eindpunt (AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet #1731).

  Alleen voor apps die Gebruikmaken van Microsoft Entra ID of Azure AD B2C met het 'algemene' eindpunt:

  var microsoftIssuerValidator = AadIssuerValidator.GetAadIssuerValidator(oidcOptions.Authority);
  oidcOptions.TokenValidationParameters.IssuerValidator = microsoftIssuerValidator.Validate;
  

Voorbeeld-app-code

Inspecteer de voorbeeld-app voor de volgende functies:

• Automatische niet-interactieve tokenvernieuwing met een aangepaste cookie opfrisser (CookieOidcRefresher.cs).
• Het serverproject roept AddAuthenticationStateSerialization aan om een verificatiestatusprovider aan de serverzijde toe te voegen die gebruikmaakt van PersistentComponentState om de verificatiestatus naar de client te laten stromen. De client roept AddAuthenticationStateDeserialization aan om te deserialiseren en de authenticatiestatus te gebruiken, zoals door de server doorgegeven. De verificatiestatus is vast voor de levensduur van de WebAssembly-toepassing.
• Aanvragen voor de Blazor Web App worden geproxied naar het back-end-web-API-project (MinimalApiJwt). MapForwarder in het bestand Program voegt direct doorsturen van HTTP-aanvragen toe die overeenkomen met het opgegeven patroon aan een specifieke bestemming met behulp van de standaardconfiguratie voor de uitgaande aanvraag, aangepaste transformaties en standaard HTTP-client:
  • Wanneer het Weather onderdeel op de server wordt weergegeven, gebruikt het onderdeel de ServerWeatherForecaster-klasse om de aanvraag voor weergegevens te proxyen met het toegangstoken van de gebruiker. IHttpContextAccessor.HttpContext bepaalt of een HttpContext beschikbaar is voor gebruik door de methode GetWeatherForecastAsync. Zie ASP.NET Core Razor-onderdelenvoor meer informatie.
  • Wanneer het onderdeel wordt weergegeven op de client, gebruikt het onderdeel de ClientWeatherForecaster-service-implementatie, die gebruikmaakt van een vooraf geconfigureerde HttpClient (in het Program-bestand van het clientproject) om een web-API-aanroep naar het serverproject uit te voeren. Een minimaal API-eindpunt (/weather-forecast) dat is gedefinieerd in het Program-bestand van het serverproject, transformeert de aanvraag met het toegangstoken van de gebruiker om de weergegevens te verkrijgen.

Voor meer informatie over (web)API-aanroepen met behulp van serviceabstracties in Blazor Web App's, zie Een web-API aanroepen vanuit een ASP.NET Core Blazor-app.

Blazor Web App project aan de clientzijde (BlazorWebAppOidc.Client)

Het BlazorWebAppOidc.Client project is het project aan de clientzijde van de Blazor Web App.

De client roept AddAuthenticationStateDeserialization aan om te deserialiseren en de authenticatiestatus te gebruiken, zoals door de server doorgegeven. De verificatiestatus is vast voor de levensduur van de WebAssembly-toepassing.

Als de gebruiker zich moet aanmelden of afmelden, is een volledige pagina opnieuw laden vereist.

De voorbeeld-app biedt alleen een gebruikersnaam en e-mail voor weergavedoeleinden. Het bevat geen tokens die worden geverifieerd bij de server bij het maken van volgende aanvragen, wat afzonderlijk werkt met behulp van een cookie die is opgenomen in HttpClient aanvragen naar de server.

Back-end-web-API-project (MinimalApiJwt)

Het MinimalApiJwt project is een back-endweb-API voor meerdere front-endprojecten. Het project configureert een minimale API--eindpunt voor weergegevens. Aanvragen van het Blazor Web App project aan de serverzijde (BlazorWebAppOidc) worden naar het MinimalApiJwt project geproxied.

Configuratie

Configureer het project in de JwtBearerOptions van de AddJwtBearer aanroep in het Program-bestand van het project:

• Audience: hiermee stelt u de doelgroep in voor een ontvangen OIDC-token.

  jwtOptions.Audience = "{APP ID URI}";
  

  Notitie

  Wanneer u Microsoft Entra ID gebruikt, koppelt u de waarde alleen aan het pad van de toepassings-ID-URI die is geconfigureerd bij het toevoegen van de Weather.Get scope onder Een API beschikbaar maken in de Azure- of Entra-portal.

  Voorbeeld:

  App-id-URI ({APP ID URI}): https://{DIRECTORY NAME}.onmicrosoft.com/{CLIENT ID}:

  • Mapnaam ({DIRECTORY NAME}): contoso
  • Applicatie-id (cliënt) ({CLIENT ID}): 00001111-aaaa-2222-bbbb-3333cccc4444

  jwtOptions.Audience = "https://contoso.onmicrosoft.com/00001111-aaaa-2222-bbbb-3333cccc4444";
  

  Het voorgaande voorbeeld heeft betrekking op een app die is geregistreerd in een tenant met een AAD B2C-tenanttype. Als de app is geregistreerd in een ME-ID-tenant, is de URI van de app-id anders, waardoor de doelgroep anders is.

  Voorbeeld:

  App-id-URI ({APP ID URI}): api://{CLIENT ID} met toepassings-id ({CLIENT ID}): 00001111-aaaa-2222-bbbb-3333cccc4444

  jwtOptions.Audience = "api://00001111-aaaa-2222-bbbb-3333cccc4444";
  

• Authority: Hiermee stelt u de instantie in voor het uitvoeren van OIDC-aanroepen. Koppel de waarde aan de autoriteit die is geconfigureerd voor de OIDC-handler in BlazorWebAppOidc/Program.cs:

  jwtOptions.Authority = "{AUTHORITY}";
  

  Voorbeeld:

  Instantie ({AUTHORITY}): https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/ (gebruikt Tenant-ID aaaabbbb-0000-cccc-1111-dddd2222eeee)

  jwtOptions.Authority = "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/";
  

  Het voorgaande voorbeeld heeft betrekking op een app die is geregistreerd in een tenant met een AAD B2C-tenanttype. Als de app is geregistreerd in een ME-ID-tenant, moet de instantie overeenkomen met de issuer (iss) van de JWT die wordt geretourneerd door de identiteitsprovider.

  jwtOptions.Authority = "https://sts.windows.net/aaaabbbb-0000-cccc-1111-dddd2222eeee/";
  

Minimale API voor weergegevens

Beveilig het eindpunt voor weersvoorspellingsgegevens in het Program-bestand van het project:

app.MapGet("/weather-forecast", () =>
{
    var forecast = Enumerable.Range(1, 5).Select(index =>
        new WeatherForecast
        (
            DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
            Random.Shared.Next(-20, 55),
            summaries[Random.Shared.Next(summaries.Length)]
        ))
        .ToArray();
    return forecast;
}).RequireAuthorization();

Voor de RequireAuthorization-extensiemethode is autorisatie vereist voor de routedefinitie. Voor controllers die u aan het project toevoegt, voegt u het kenmerk [Authorize] toe aan de controller of actie.

Omleiden naar de startpagina bij afmelding

Met het LogInOrOut-onderdeel (Layout/LogInOrOut.razor) wordt een verborgen veld ingesteld voor de retour-URL (ReturnUrl) op de huidige URL (currentURL). Wanneer de gebruiker zich afmeldt bij de app, retourneert de id-provider de gebruiker naar de pagina van waaruit ze zijn afgemeld. Als de gebruiker zich afmeldt vanaf een beveiligde pagina, wordt deze teruggezet naar dezelfde beveiligde pagina en teruggestuurd via het verificatieproces. Deze verificatiestroom is redelijk wanneer gebruikers regelmatig accounts moeten wijzigen.

U kunt ook het volgende LogInOrOut-onderdeel gebruiken, dat geen retour-URL levert wanneer u zich afmeldt.

Layout/LogInOrOut.razor:

<div class="nav-item px-3">
    <AuthorizeView>
        <Authorized>
            <form action="authentication/logout" method="post">
                <AntiforgeryToken />
                <button type="submit" class="nav-link">
                    <span class="bi bi-arrow-bar-left-nav-menu" aria-hidden="true">
                    </span> Logout @context.User.Identity?.Name
                </button>
            </form>
        </Authorized>
        <NotAuthorized>
            <a class="nav-link" href="authentication/login">
                <span class="bi bi-person-badge-nav-menu" aria-hidden="true"></span> 
                Login
            </a>
        </NotAuthorized>
    </AuthorizeView>
</div>

Token vernieuwen

De implementatie van de aangepaste cookie (CookieOidcRefresher.cs) werkt de claims van de gebruiker automatisch bij wanneer deze verlopen. De huidige implementatie verwacht een id-token te ontvangen van het tokeneindpunt in ruil voor het vernieuwingstoken. De claims in dit id-token worden vervolgens gebruikt om de claims van de gebruiker te overschrijven.

De voorbeeld-implementatie bevat geen code voor het aanvragen van claims van het UserInfo-eindpunt bij het vernieuwen van tokens. Zie BlazorWebAppOidc AddOpenIdConnect with GetClaimsFromUserInfoEndpoint = true doesn't propogate role claims to client (dotnet/aspnetcore #58826)voor meer informatie.

Notitie

Sommige id-providers retourneren alleen een toegangstoken bij het gebruik van een vernieuwstoken. De CookieOidcRefresher kan worden bijgewerkt met aanvullende logica om de eerdere set claims die zijn opgeslagen in de verificatie-cookie te blijven gebruiken of het toegangstoken te gebruiken om claims aan te vragen vanaf het eindpunt UserInfo.

Cryptografische nonce

Een niet- is een tekenreekswaarde die de sessie van een client koppelt aan een id-token om herhalingsaanvallente beperken.

Als u een nonce-fout ontvangt tijdens het ontwikkelen en testen van de authenticatie, gebruik dan voor elke testrun een nieuwe InPrivate- of incognitobrowsersessie, ongeacht hoe klein de wijziging in de app of testgebruiker is. Verouderde cookie-gegevens kunnen namelijk leiden tot een nonce-fout. Zie de sectie Cookies en sitegegevens voor meer informatie.

Er is geen nonce vereist of gebruikt bij het uitwisselen van een refresh token voor een nieuw toegangstoken. In de voorbeeld-app stelt de CookieOidcRefresher (CookieOidcRefresher.cs) opzettelijk OpenIdConnectProtocolValidator.RequireNonce in op false.

Toepassingsrollen voor apps die niet zijn geregistreerd bij Microsoft Entra (ME-ID)

Deze sectie heeft betrekking op apps die geen gebruik maken van Microsoft Entra ID (ME-ID) als id-provider. Zie de sectie Toepassingsrollen voor apps die zijn geregistreerd bij Microsoft Entra (ME-ID) voor apps die zijn geregistreerd bij ME-ID.

Configureer het rolclaimtype (TokenValidationParameters.RoleClaimType) in de OpenIdConnectOptions van Program.cs:

oidcOptions.TokenValidationParameters.RoleClaimType = "{ROLE CLAIM TYPE}";

Voor veel OIDC-identity providers is het type rolclaim role. Raadpleeg de documentatie van uw id-provider voor de juiste waarde.

Vervang de UserInfo-klasse in het BlazorWebAppOidc.Client-project door de volgende klasse.

UserInfo.cs:

using Microsoft.AspNetCore.Components.WebAssembly.Authentication;
using System.Security.Claims;

namespace BlazorWebAppOidc.Client;

// Add properties to this class and update the server and client 
// AuthenticationStateProviders to expose more information about 
// the authenticated user to the client.
public sealed class UserInfo
{
    public required string UserId { get; init; }
    public required string Name { get; init; }
    public required string[] Roles { get; init; }

    public const string UserIdClaimType = "sub";
    public const string NameClaimType = "name";
    private const string RoleClaimType = "role";

    public static UserInfo FromClaimsPrincipal(ClaimsPrincipal principal) =>
        new()
        {
            UserId = GetRequiredClaim(principal, UserIdClaimType),
            Name = GetRequiredClaim(principal, NameClaimType),
            Roles = principal.FindAll(RoleClaimType).Select(c => c.Value)
                .ToArray(),
        };

    public ClaimsPrincipal ToClaimsPrincipal() =>
        new(new ClaimsIdentity(
            Roles.Select(role => new Claim(RoleClaimType, role))
                .Concat([
                    new Claim(UserIdClaimType, UserId),
                    new Claim(NameClaimType, Name),
                ]),
            authenticationType: nameof(UserInfo),
            nameType: NameClaimType,
            roleType: RoleClaimType));

    private static string GetRequiredClaim(ClaimsPrincipal principal,
        string claimType) =>
            principal.FindFirst(claimType)?.Value ??
            throw new InvalidOperationException(
                $"Could not find required '{claimType}' claim.");
}

Op dit moment kunnen Razor onderdelen op rollen gebaseerde en op beleid gebaseerde autorisatie. Toepassingsrollen worden weergegeven in role claims, één claim per rol.

Toepassingsrollen voor apps die zijn geregistreerd bij Microsoft Entra (ME-ID)

Gebruik de richtlijnen in deze sectie voor het implementeren van toepassingsrollen, ME-ID beveiligingsgroepen en ME-ID ingebouwde beheerdersrollen voor apps met behulp van Microsoft Entra ID (ME-ID).

De methode die in deze sectie wordt beschreven, configureert ME-ID om groepen en rollen in de authenticatie-header cookie te verzenden. Wanneer gebruikers slechts lid zijn van een paar beveiligingsgroepen en rollen, moet de volgende benadering werken voor de meeste hostingplatformen zonder dat er een probleem optreedt waarbij headers te lang zijn, bijvoorbeeld bij IIS-hosting met een standaardlimiet voor de headerlengte van 16 kB (MaxRequestBytes). Als de lengte van de header een probleem is vanwege een hoog groeps- of rollidmaatschap, raden we u aan de richtlijnen in deze sectie niet te volgen, namelijk het implementeren van Microsoft Graph om de groepen en rollen van een gebruiker afzonderlijk ME-ID te verkrijgen, een benadering die de grootte van de authenticatiestap cookieniet vergroot. Zie Ongeldige aanvraag - Aanvraag te lang - IIS-server (dotnet/aspnetcore #57545)voor meer informatie.

Configureer het rolclaimtype (TokenValidationParameters.RoleClaimType) in OpenIdConnectOptions van Program.cs. Stel de waarde in op roles:

oidcOptions.TokenValidationParameters.RoleClaimType = "roles";

Hoewel u rollen niet kunt toewijzen aan groepen zonder een ME-ID Premium-account, kunt u rollen toewijzen aan gebruikers en rolclaims ontvangen voor gebruikers met een standaard Azure-account. Voor de richtlijnen in deze sectie is geen ME-ID Premium-account vereist.

Wanneer u met de standaarddirectory werkt, volgt u de richtlijnen in App-rollen toevoegen aan uw toepassing en ze in het token ontvangen (ME-ID documentatie), om rollen te configureren en toe te wijzen. Als u niet met de standaardmap werkt, bewerkt u het manifest van de app in Azure Portal om de rollen van de app handmatig in te stellen in de appRoles vermelding van het manifestbestand. Zie De rolclaim configureren (ME-ID documentatie)voor meer informatie.

De Azure-beveiligingsgroepen van een gebruiker komen binnen als groups-claims, en de ingebouwde ME-ID-beheerdersroltoewijzingen komen binnen als -bekende-ID's (wids)-claims. Waarden voor beide claimtypen zijn GUID's. Wanneer deze claims door de app worden ontvangen, zijn ze bruikbaar om rol- en beleidsautorisatie vast te stellen in Razor onderdelen.

Stel in het manifest van de app in de Azure-portal het kenmerk groupMembershipClaims in opAll. Een waarde van All zorgt ervoor dat ME-ID alle beveiligings-/distributiegroepen (groups claims) en rollen (wids claims) van de aangemelde gebruiker verzendt. Het kenmerk groupMembershipClaims instellen:

1. Open de registratie van de app in Azure Portal.
2. Selecteer >manifest beheren in de zijbalk.
3. Zoek het kenmerk groupMembershipClaims.
4. Stel de waarde in op All ("groupMembershipClaims": "All").
5. Selecteer de knop Save.

Vervang de UserInfo-klasse in het BlazorWebAppOidc.Client-project door de volgende klasse.

UserInfo.cs:

using Microsoft.AspNetCore.Components.WebAssembly.Authentication;
using System.Security.Claims;

namespace BlazorWebAppOidc.Client;

// Add properties to this class and update the server and client 
// AuthenticationStateProviders to expose more information about 
// the authenticated user to the client.
public sealed class UserInfo
{
    public required string UserId { get; init; }
    public required string Name { get; init; }
    public required string[] Roles { get; init; }
    public required string[] Groups { get; init; }
    public required string[] Wids { get; init; }

    public const string UserIdClaimType = "sub";
    public const string NameClaimType = "name";
    private const string RoleClaimType = "roles";
    private const string GroupsClaimType = "groups";
    private const string WidsClaimType = "wids";

    public static UserInfo FromClaimsPrincipal(ClaimsPrincipal principal) =>
        new()
        {
            UserId = GetRequiredClaim(principal, UserIdClaimType),
            Name = GetRequiredClaim(principal, NameClaimType),
            Roles = principal.FindAll(RoleClaimType).Select(c => c.Value)
                .ToArray(),
            Groups = principal.FindAll(GroupsClaimType).Select(c => c.Value)
                .ToArray(),
            Wids = principal.FindAll(WidsClaimType).Select(c => c.Value)
                .ToArray(),
        };

    public ClaimsPrincipal ToClaimsPrincipal() =>
        new(new ClaimsIdentity(
            Roles.Select(role => new Claim(RoleClaimType, role))
                .Concat(Groups.Select(role => new Claim(GroupsClaimType, role)))
                .Concat(Wids.Select(role => new Claim(WidsClaimType, role)))
                .Concat([
                    new Claim(UserIdClaimType, UserId),
                    new Claim(NameClaimType, Name),
                ]),
            authenticationType: nameof(UserInfo),
            nameType: NameClaimType,
            roleType: RoleClaimType));

    private static string GetRequiredClaim(ClaimsPrincipal principal,
        string claimType) =>
            principal.FindFirst(claimType)?.Value ??
            throw new InvalidOperationException(
                $"Could not find required '{claimType}' claim.");
}

Op dit moment kunnen Razor onderdelen autorisatie op basis van rollen en beleidaannemen:

• Toepassingsrollen worden weergegeven in roles claims, één claim per rol.
• Beveiligingsgroepen worden weergegeven in groups claims, één claim per groep. De GUID's van de beveiligingsgroep worden weergegeven in Azure Portal wanneer u een beveiligingsgroep maakt en worden weergegeven bij het selecteren van Identity>Overzicht>Groepen>Weergave.
• Ingebouwde ME-ID beheerdersrollen worden weergegeven in wids claims, één claim per rol. De wids claim met een waarde van b79fbf4d-3ef9-4689-8143-76b194e85509 wordt altijd verzonden door ME-ID voor niet-gastaccounts van de tenant en verwijst niet naar een beheerdersrol. GUID's voor beheerdersrol (rolsjabloon-id's) worden weergegeven in Azure Portal wanneer u rollen & beheerdersselecteert, gevolgd door het beletselteken (...) >Beschrijving voor de vermelde rol. De sjabloon-id's van rollen worden ook vermeld in Microsoft Entra ingebouwde rollen (Entra-documentatie).

Problemen oplossen

Loggen

De server-app is een standaard-ASP.NET Core-app. Zie de richtlijnen voor ASP.NET Core-logboekregistratie om een lager niveau voor logboekregistratie in te schakelen in de server-app.

Als u debug- of traceringslogboekregistratie wilt inschakelen voor Blazor WebAssembly-verificatie, raadpleegt u de sectie clientzijde logboekregistratie van ASP.NET Core Blazor logging met de versiekeuze voor artikelen ingesteld op ASP.NET Core 7.0 of hoger.

Veelvoorkomende fouten

• Onjuiste configuratie van de app of Identity Provider (IP)

  De meest voorkomende fouten worden veroorzaakt door onjuiste configuratie. Hier volgen enkele voorbeelden:

  • Afhankelijk van wat vereist is in het scenario, voorkomt een ontbrekende of onjuiste Authority, Instance, tenant-id, tenantdomein, client-id of omleidings-URI dat een app clients kan authentiseren.
  • Onjuiste aanvraagbereiken voorkomen dat clients toegang hebben tot eindpunten van de serverweb-API.
  • Onjuiste of ontbrekende server-API-machtigingen voorkomen dat clients toegang hebben tot web-API-eindpunten van de server.
  • Het uitvoeren van de app op een andere poort dan is geconfigureerd in de omleidings-URI van de app-registratie van het IP-adres. Houd er rekening mee dat een poort niet vereist is voor Microsoft Entra ID en een app die wordt uitgevoerd op een localhost ontwikkelingstestadres, maar de poortconfiguratie van de app en de poort waarop de app wordt uitgevoerd, moet overeenkomen met niet-localhost adressen.

  De configuratiedekking in dit artikel laat voorbeelden zien van de juiste configuratie. Controleer zorgvuldig de configuratie, kijkend naar misconfiguraties van apps en IP-adressen.

  Als de configuratie correct wordt weergegeven:

  • Toepassingslogboeken analyseren.

  • Controleer het netwerkverkeer tussen de client-app en de IP- of server-app met de ontwikkelhulpprogramma's van de browser. Vaak wordt een exacte foutmelding of een bericht met een aanwijzing voor wat het probleem veroorzaakt, geretourneerd door de IP- of server-app nadat een verzoek is ingediend. Richtlijnen voor ontwikkelhulpprogramma's vindt u in de volgende artikelen:

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

  Het documentatieteam reageert op documentfeedback en fouten in artikelen (open een probleem in de sectie Deze pagina feedback), maar kan geen productondersteuning bieden. Er zijn verschillende openbare ondersteuningsforums beschikbaar om u te helpen bij het oplossen van problemen met een app. U wordt aangeraden het volgende te doen:

  • Stack Overflow (tag: blazor)
  • ASP.NET Core Slack Team
  • Blazor Traliewerk

  De voorgaande forums zijn niet eigendom van of worden beheerd door Microsoft.

  Voor foutrapporten over niet-beveiliging, niet-gevoelige en niet-vertrouwelijke reproduceerbare frameworks, een probleem openen met de ASP.NET Core-producteenheid. Open geen melding bij de productafdeling totdat je de oorzaak van een probleem grondig hebt onderzocht en het niet zelf of met behulp van de community op een openbaar helpforum kunt oplossen. De producteenheid kan geen problemen met afzonderlijke apps oplossen die zijn verbroken vanwege eenvoudige onjuiste configuratie of gebruiksscenario's met betrekking tot services van derden. Als een rapport gevoelig of vertrouwelijk van aard is of een mogelijke beveiligingsfout in het product beschrijft die cyberaanvallers kunnen misbruiken, raadpleegt u Beveiligingsproblemen en bugs (dotnet/aspnetcore GitHub-opslagplaats) melden.

• Niet-geautoriseerde client voor ME-ID

  info: Autorisatie van Microsoft.AspNetCore.Authorization.DefaultAuthorizationService[2] is mislukt. Aan deze vereisten is niet voldaan: DenyAnonymousAuthorizationRequirement: Vereist een geverifieerde gebruiker.

  Aanmeldingsoproepfout van ME-ID:

  • Fout: unauthorized_client
  • Beschrijving: AADB2C90058: The provided application is not configured to allow public clients.

  De fout oplossen:

  1. Open in Azure Portal het manifest van de -app.
  2. Stel de allowPublicClient kenmerk- in op null of true.

Cookies en sitegegevens

Cookies en sitegegevens kunnen worden bewaard in app-updates en kunnen het testen en oplossen van problemen verstoren. Wis het volgende bij het aanbrengen van app-codewijzigingen, wijzigingen in gebruikersaccounts bij de provider of wijzigingen in de configuratie van de provider-app:

• Aanmeldingscookies van gebruikers
• App-cookies
• Sitegegevens in cache en opgeslagen

Een benadering om te voorkomen dat achterblijvende cookies en sitegegevens het testen en oplossen van problemen verstoren, is het volgende:

• Een browser configureren
  • Gebruik een browser om te testen dat u kunt configureren om alle cookie en sitegegevens te verwijderen telkens wanneer de browser wordt gesloten.
  • Zorg ervoor dat de browser handmatig of door de IDE is gesloten voor een wijziging in de configuratie van de app, testgebruiker of provider.
• Gebruik een aangepaste opdracht om een browser te openen in de InPrivate- of Incognitomodus in Visual Studio:
  • Open dialoogvenster Bladeren met vanuit de knop Uitvoeren van Visual Studio.
  • Selecteer de knop Toevoegen.
  • Geef het pad naar uw browser op in het veld Program. De volgende uitvoerbare paden zijn typische installatielocaties voor Windows 10. Als uw browser is geïnstalleerd op een andere locatie of als u Windows 10 niet gebruikt, geeft u het pad op naar het uitvoerbare bestand van de browser.
    • 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
  • Geef in het veld Argumenten de opdrachtregeloptie op die de browser gebruikt om in de InPrivate- of Incognitomodus te openen. Voor sommige browsers is de URL van de app vereist.
    • Microsoft Edge: gebruik -inprivate.
    • Google Chrome: gebruik --incognito --new-window {URL}, waarbij de {URL} tijdelijke aanduiding de URL is die moet worden geopend (bijvoorbeeld https://localhost:5001).
    • Mozilla Firefox: Gebruik -private -url {URL}, waarbij {URL} de tijdelijke aanduiding voor de URL is die moet worden geopend (bijvoorbeeld https://localhost:5001).
  • Geef een naam op in het veld Vriendelijke naam. Bijvoorbeeld Firefox Auth Testing.
  • Selecteer de knop OK.
  • Om te voorkomen dat u het browserprofiel moet selecteren voor elke iteratie van het testen met een app, stelt u het profiel in als de standaardinstelling met de knop Als standaard instellen.
  • Zorg ervoor dat de browser wordt gesloten door de IDE voor elke wijziging in de app, testgebruiker of providerconfiguratie.

App-upgrades

Een werkende app kan onmiddellijk mislukken na het upgraden van de .NET Core SDK op de ontwikkelcomputer of het wijzigen van pakketversies in de app. In sommige gevallen kunnen incoherent pakketten een app breken bij het uitvoeren van belangrijke upgrades. De meeste van deze problemen kunnen worden opgelost door de volgende instructies te volgen:

1. Wis de NuGet-pakketcaches van het lokale systeem door dotnet nuget locals all --clear uit te voeren vanuit een opdrachtshell.
2. Verwijder de bin en obj mappen van het project.
3. Herstel het project en bouw het opnieuw.
4. Verwijder alle bestanden in de implementatiemap op de server voordat u de app opnieuw implementeert.

Notitie

Het gebruik van pakketversies die niet compatibel zijn met het doelframework van de app, wordt niet ondersteund. Gebruik de NuGet Gallery of FuGet Package Explorervoor informatie over een pakket.

De server-app uitvoeren

Zorg er bij het testen en oplossen van problemen met Blazor Web Appvoor dat u de app uitvoert vanuit het serverproject.

De gebruiker inspecteren

Het volgende UserClaims onderdeel kan rechtstreeks in apps worden gebruikt of dienen als basis voor verdere aanpassing.

UserClaims.razor:

@page "/user-claims"
@using System.Security.Claims
@using Microsoft.AspNetCore.Authorization
@attribute [Authorize]

<PageTitle>User Claims</PageTitle>

<h1>User Claims</h1>

@if (claims.Any())
{
    <ul>
        @foreach (var claim in claims)
        {
            <li><b>@claim.Type:</b> @claim.Value</li>
        }
    </ul>
}

@code {
    private IEnumerable<Claim> claims = Enumerable.Empty<Claim>();

    [CascadingParameter]
    private Task<AuthenticationState>? AuthState { get; set; }

    protected override async Task OnInitializedAsync()
    {
        if (AuthState == null)
        {
            return;
        }

        var authState = await AuthState;
        claims = authState.User.Claims;
    }
}

Aanvullende informatiebronnen

• AzureAD/microsoft-identity-web GitHub-opslagplaats: Nuttige richtlijnen voor het implementeren van Microsoft Identity Web for Microsoft Entra ID en Azure Active Directory B2C voor ASP.NET Core-apps, waaronder koppelingen naar voorbeeld-apps en gerelateerde Azure-documentatie. Op dit moment worden Blazor Web Appniet expliciet behandeld in de Azure-documentatie, maar de installatie en configuratie van een Blazor Web App voor ME-ID en Azure-hosting is hetzelfde als voor elke ASP.NET Core-web-app.
• AuthenticationStateProvider
• Authenticatiestatus beheren in Blazor Web App
• token vernieuwen tijdens http-aanvraag in Blazor Interactive Server met OIDC (dotnet/aspnetcore #55213)