Proteggere un ASP.NET Core Blazor Web App con OpenID Connect (OIDC)

2025-04-30

Nota

Questa non è la versione più recente di questo articolo. Per la versione corrente, vedere la versione .NET 9 di questo articolo.

Importante

Queste informazioni si riferiscono a un prodotto non definitive che può essere modificato in modo sostanziale prima che venga rilasciato commercialmente. Microsoft non riconosce alcuna garanzia, espressa o implicita, in merito alle informazioni qui fornite.

Per la versione corrente, vedere la versione .NET 9 di questo articolo.

Questo articolo descrive come proteggere un con OpenID Connect (OIDC) utilizzando un'app di esempio nel repository GitHub (.NET 8 o versioni successive) (come scaricare).

Per Microsoft Entra ID o Azure AD B2C, è possibile usare AddMicrosoftIdentityWebApp di Microsoft da Identity Web (Microsoft.Identity.Web pacchetto NuGet, documentazione dell'API), che aggiunge sia i gestori di autenticazione OIDC Cookie con le impostazioni predefinite appropriate. L'app di esempio e le indicazioni contenute in questo articolo non usano Microsoft Identity Web. Le linee guida illustrano come configurare manualmente il gestore OIDC per qualsiasi provider OIDC. Per altre informazioni sull'implementazione di Microsoft Identity Web, vedere Proteggere un ASP.NET Core Blazor Web App con Microsoft Entra ID.

Questa versione dell'articolo illustra l'implementazione di OIDC senza adottare il modello Backend per Frontend (BFF) con un'applicazione che utilizza il rendering automatico interattivo globale nei progetti server e . Il modello BFF è utile per effettuare richieste autenticate a servizi esterni. Modificare il selettore della versione dell'articolo in modello BFF se la specifica dell'app richiede l'adozione del modello BFF.

Viene adottata la specifica seguente:

Blazor Web App usa la modalità di rendering automatico con interattività globale.
I servizi dei provider di stato di autenticazione personalizzati vengono utilizzati dai server e dalle app client per acquisire lo stato di autenticazione dell'utente e trasferirlo tra server e client.
Questa app è un punto di partenza per qualsiasi flusso di autenticazione OIDC. OIDC viene configurato manualmente nell'app e non si basa su Microsoft Entra ID o pacchetti Web MicrosoftIdentity, né l'app di esempio richiede l'hosting di Microsoft Azure. Tuttavia, l'app di esempio può essere usata con Entra, Microsoft Identity Web e ospitata in Azure.
Aggiornamento automatico non interattivo del token.
Un progetto API Web separato illustra una chiamata API Web sicura per i dati meteo.

Per un'esperienza alternativa con Microsoft Authentication Library per .NET, Microsoft Identity Web e Microsoft Entra ID, vedere Proteggere un ASP.NET Core Blazor Web App con Microsoft Entra ID.

Soluzione di esempio

L'app di esempio è costituita dai progetti seguenti:

BlazorWebAppOidc: progetto lato server di Blazor Web App, contenente un esempio endpoint API minimo per i dati meteo.
BlazorWebAppOidc.Client: progetto lato client di Blazor Web App.
MinimalApiJwt: API Web back-end con un endpoint API minimo per i dati meteo.

Accedere all'esempio tramite la cartella versione più recente nel Blazor repository degli esempi con il collegamento seguente. L'esempio si trova nella BlazorWebAppOidc cartella per .NET 8 o versione successiva.

Avviare la soluzione dal Aspire/Aspire.AppHost progetto.

Visualizzare o scaricare il codice di esempio (come scaricare)

Funzionalità della soluzione di esempio:

Rinnovo automatico del token non interattivo con l'aiuto di un aggiornatore personalizzato cookie (CookieOidcRefresher.cs).
I dati meteo vengono gestiti da un endpoint API minimo (/weather-forecast) nel Program file (Program.cs) del MinimalApiJwt progetto. L'endpoint richiede l'autorizzazione chiamando RequireAuthorization. Per tutti i controller aggiunti al progetto, aggiungere l'attributo[Authorize] al controller o all'azione. Per altre informazioni su come richiedere l'autorizzazione nell'app tramite un criterio di autorizzazione e rifiutare esplicitamente l'autorizzazione in un subset di endpoint pubblici, vedere le Razor linee guida OIDC per le pagine.
L'app chiama in modo sicuro un'API Web per i dati meteo:
- Quando si esegue il rendering del componente Weather sul server, il componente utilizza ServerWeatherForecaster sul server per ottenere i dati meteo dall'API web nel progetto MinimalApiJwt utilizzando un DelegatingHandler (TokenHandler) che aggancia il token di accesso da HttpContext alla richiesta.
- Quando viene eseguito il rendering del componente nel client, il componente usa l'implementazione del servizio ClientWeatherForecaster, che utilizza un HttpClient preconfigurato (nel file del progetto del client Program) per effettuare la chiamata all'API web dal progetto del server ServerWeatherForecaster.

Il progetto server chiama AddAuthenticationStateSerialization per aggiungere un provider di stato di autenticazione lato server che usa PersistentComponentState per trasferire lo stato di autenticazione al client. Il client chiama AddAuthenticationStateDeserialization per deserializzare e usare lo stato di autenticazione passato dal server. Lo stato di autenticazione è fisso per la durata dell'applicazione WebAssembly.

La PersistingAuthenticationStateProvider classe (PersistingAuthenticationStateProvider.cs) è un componente lato AuthenticationStateProvider server che usa PersistentComponentState per trasferire lo stato di autenticazione al client, che viene quindi mantenuto per la durata dell'applicazione WebAssembly.

Per altre informazioni sulle chiamate API (Web) usando astrazioni di un servizio in Blazor Web Apps, vedere Chiamare un'API Web da un'app ASP.NET CoreBlazor.

Registrazioni dell'app Microsoft Entra ID

È consigliabile usare registrazioni separate per app e API Web, anche quando le app e le API Web si trovano nella stessa soluzione. Le indicazioni seguenti sono relative all'app BlazorWebAppOidc e MinimalApiJwt all'API Web della soluzione di esempio, ma le stesse linee guida si applicano in genere a tutte le registrazioni basate su Entra per le app e le API Web.

Registrare prima l'API Web (MinimalApiJwt) in modo da poter quindi concedere l'accesso all'API Web durante la registrazione dell'app. L'ID tenant e l'ID client dell'API Web vengono usati per configurare l'API Web nel file Program . Dopo aver registrato l'API Web, esporre l'API Web in Registrazioni delle app>Esporre un'API con un nome di ambito di Weather.Get. Registrare l'URI ID app da usare nella configurazione dell'app.

Registrare quindi l'app (BlazorWebAppOidc/BlazorWebApOidc.Client) con una configurazione della piattaforma Web e un URI di reindirizzamento di https://localhost/signin-oidc (una porta non è necessaria). L'ID tenant e l'ID client dell'app, insieme all'indirizzo di base dell'API Web, all'URI ID app e al nome dell'ambito meteo, vengono usati per configurare l'app nel file Program . Concedere l'autorizzazione all'API per accedere all'API web in Registrazioni app>Autorizzazioni API. Se la specifica di sicurezza dell'app lo richiede, è possibile concedere all'organizzazione il consenso amministratore per accedere all'API Web. Gli utenti e i gruppi autorizzati vengono assegnati alla registrazione dell'app in Registrazioni app>Applicazioni aziendali.

Nella configurazione della registrazione dell'applicazione per la Concessione implicita e i flussi ibridi del portale Entra o Azure, non selezionare nessuna delle opzioni per far sì che l'endpoint di autorizzazione restituisca token di accesso o token ID. Il gestore OpenID Connect richiede automaticamente i token appropriati usando il codice restituito dall'endpoint di autorizzazione.

Creare un segreto client nella registrazione dell'app nel portale entra o di Azure (Gestisci>certificati e segreti>Nuovo segreto client). Conserva il valore del segreto del client per utilizzarlo nella sezione successiva.

Altre indicazioni sulla configurazione di Entra per impostazioni specifiche sono disponibili più avanti in questo articolo.

Impostare il segreto del client

Questa sezione si applica solo al progetto server Blazor Web App (BlazorWebAppOidc project).

Avviso

Non archiviare segreti dell'app, stringhe di connessione, credenziali, password, numeri di identificazione personale (PIN), codice C#/.NET privato o chiavi/token privati nel codice lato client, che è sempre non sicuro. Negli ambienti di test/gestione temporanea e produzione, il codice lato Blazor server e le API Web devono usare flussi di autenticazione sicuri che evitano di mantenere le credenziali all'interno del codice del progetto o dei file di configurazione. Al di fuori dei test di sviluppo locali, è consigliabile evitare l'uso di variabili di ambiente per archiviare i dati sensibili, perché le variabili di ambiente non sono l'approccio più sicuro. Per i test di sviluppo locali, lo strumento Secret Manager è consigliato per proteggere i dati sensibili. Per altre informazioni, vedere Gestire in modo sicuro dati e credenziali sensibili.

Per i test di sviluppo locali, usare lo strumento Secret Manager per archiviare il Blazor segreto client del progetto server nella chiave Authentication:Schemes:MicrosoftOidc:ClientSecretdi configurazione .

Il Blazor progetto server non è stato inizializzato per lo strumento Secret Manager. Usare una shell dei comandi, ad esempio la shell dei comandi di Developer PowerShell in Visual Studio, per eseguire il comando seguente. Prima di eseguire il comando, cambia la directory usando il comando cd per accedere alla directory del progetto server. Il comando stabilisce un identificatore di segreti utente (<UserSecretsId> nel file di progetto dell'app server):

dotnet user-secrets init

Eseguire il comando seguente per impostare il segreto client. Il {SECRET} segnaposto è il segreto client ottenuto dalla registrazione dell'app:

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

Se si usa Visual Studio, è possibile verificare che il segreto sia impostato facendo clic con il pulsante destro del mouse sul progetto server in Esplora soluzioni e scegliendo Gestisci segreti utente.

`MinimalApiJwt` progetto

Il MinimalApiJwt progetto è un'API Web back-end per più progetti front-end. Il progetto configura un endpoint API minimo per i dati meteo.

Il MinimalApiJwt.http file può essere usato per testare la richiesta di dati meteo. Si noti che il progetto MinimalApiJwt deve essere in esecuzione per testare l'endpoint, e l'endpoint è codificato staticamente nel file. Per altre informazioni, vedere Usare file .http in Visual Studio 2022.

Il progetto include pacchetti e configurazione per produrre documenti OpenAPI e l'interfaccia utente di Swagger nell'ambiente di sviluppo. Per altre informazioni, vedere Usare i documenti OpenAPI generati.

Il progetto crea un endpoint API minimo per i dati meteo:

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

Configurare il progetto nella JwtBearerOptions della chiamata AddJwtBearer nel file Program del progetto.

Authority imposta l'Autorità per effettuare chiamate OIDC. È consigliabile usare una registrazione dell'app separata per il MinimalApiJwt progetto. L'autorità corrisponde all'emittente (iss) del token JWT restituito dal provider di identità.

jwtOptions.Authority = "{AUTHORITY}";

Il formato dell'autorità dipende dal tipo di tenant in uso. Gli esempi seguenti per Microsoft Entra ID usano un ID tenant di aaaabbbb-0000-cccc-1111-dddd2222eeee.

esempio di autorità del tenant ME-ID:

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

Esempio di autorità tenant AAD B2C:

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

Imposta Audience il gruppo di destinatari per qualsiasi token OIDC ricevuto.

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

Nota

Quando si usa Microsoft Entra ID, associare il valore solo al percorso dell'URI ID applicazione configurato quando si aggiunge l'ambito Weather.Get in Esporre un'API nel portale Entra o Azure. Non includere il nome dell'ambito "Weather.Get" nel valore.

Il formato del gruppo di destinatari dipende dal tipo di tenant in uso. Gli esempi seguenti per Microsoft Entra ID usano un ID tenant di contoso e un ID client di 11112222-bbbb-3333-cccc-4444dddd5555.

ME-ID esempio di URI ID app tenant:

jwtOptions.Audience = "api://11112222-bbbb-3333-cccc-4444dddd5555";

Esempio di URI dell'ID dell'app tenant di AAD B2C:

jwtOptions.Audience = "https://contoso.onmicrosoft.com/11112222-bbbb-3333-cccc-4444dddd5555";

Blazor Web App progetto server (`BlazorWebAppOidc`)

Il progetto BlazorWebAppOidc è il progetto per il lato server di Blazor Web App.

Un DelegatingHandler (TokenHandler) gestisce il collegamento del token di accesso di un utente alle richieste in uscita. Il gestore di token viene eseguito solo durante il rendering statico lato server (SSR statico), quindi l'uso di HttpContext è sicuro in questo scenario. Per ulteriori informazioni, vedere IHttpContextAccessor/HttpContext nelle app ASP.NET CoreBlazor e ASP.NET Core lato server e Blazor Web App scenari di sicurezza aggiuntivi.

TokenHandler.cs:

public class TokenHandler(IHttpContextAccessor httpContextAccessor) : 
    DelegatingHandler
{
    protected override async Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request, CancellationToken cancellationToken)
    {
        if (httpContextAccessor.HttpContext is null)
        {
            throw new Exception("HttpContext not available");
        }

        var accessToken = await httpContextAccessor.HttpContext
            .GetTokenAsync("access_token");

        request.Headers.Authorization =
            new AuthenticationHeaderValue("Bearer", accessToken);

        return await base.SendAsync(request, cancellationToken);
    }
}

Nel file del Program progetto il gestore di token (TokenHandler) viene registrato come servizio e specificato come gestore messaggi con AddHttpMessageHandler per effettuare richieste sicure all'API Web back-end MinimalApiJwt usando un client HTTP denominato ("ExternalApi").

builder.Services.AddScoped<TokenHandler>();

builder.Services.AddHttpClient("ExternalApi",
      client => client.BaseAddress = new Uri(builder.Configuration["ExternalApiUri"] ?? 
          throw new Exception("Missing base address!")))
      .AddHttpMessageHandler<TokenHandler>();

Nel file del appsettings.json progetto configurare l'URI dell'API esterna:

"ExternalApiUri": "{BASE ADDRESS}"

Esempio:

"ExternalApiUri": "https://localhost:7277"

La seguente configurazione OpenIdConnectOptions è trovata nel file del progetto Program nella chiamata a AddOpenIdConnect:

PushedAuthorizationBehavior: controlla il supporto delle richieste di autorizzazione push (PAR). Per impostazione predefinita, l'impostazione consiste nell'usare PAR se il documento di individuazione del provider di identità (in genere presente in .well-known/openid-configuration) annuncia il supporto per PAR. Se si desidera richiedere il supporto PAR per l'app, è possibile assegnare un valore di PushedAuthorizationBehavior.Require. PAR non è supportato da Microsoft Entra e non sono previsti piani per Entra per supportarlo in futuro.

oidcOptions.PushedAuthorizationBehavior = PushedAuthorizationBehavior.UseIfAvailable;

SignInScheme: imposta lo schema di autenticazione corrispondente al middleware responsabile della persistenza dell'identità dell'utente dopo un'autenticazione riuscita. Il gestore OIDC deve usare uno schema di accesso in grado di rendere persistenti le credenziali utente tra le richieste. La seguente riga è presente solo a scopo dimostrativo. Se omesso, DefaultSignInScheme viene usato come valore di fallback.

oidcOptions.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;

Ambiti per openid e profile (Scope) (facoltativo): Gli ambiti openid e profile sono anch'essi configurati per impostazione predefinita perché sono necessari per il funzionamento del gestore OIDC, ma potrebbe essere necessario aggiungerli nuovamente se gli ambiti sono inclusi nella configurazione Authentication:Schemes:MicrosoftOidc:Scope. Per indicazioni generali sulla configurazione, vedere Configurazione in ASP.NET Core e configurazione di ASP.NET CoreBlazor.

oidcOptions.Scope.Add(OpenIdConnectScope.OpenIdProfile);

SaveTokens: definisce se i token di accesso e aggiornamento devono essere archiviati in AuthenticationProperties dopo un'autorizzazione riuscita. Questa proprietà è impostata su true in modo che il token di rinnovo venga archiviato per il rinnovo del token non interattivo.

oidcOptions.SaveTokens = true;

Ambito per l'accesso offline (Scope): l'ambito offline_access è obbligatorio per il token di aggiornamento.

oidcOptions.Scope.Add(OpenIdConnectScope.OfflineAccess);

Authority e ClientId: imposta l'autorità e l'ID client per le chiamate OIDC.

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

L'esempio seguente usa un ID tenant di aaaabbbb-0000-cccc-1111-dddd2222eeee e un ID client di 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";

Per le app multi-tenant, è consigliabile usare l'autorità "comune". È anche possibile usare l'autorità "comune" per le app a tenant singolo, ma è necessaria una configurazione personalizzata IssuerValidator, come illustrato più avanti in questa sezione.

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

ResponseType: configura il gestore OIDC per eseguire solo il flusso del codice di autorizzazione. Le concessioni implicite e i flussi ibridi non sono necessari in questa modalità. Il gestore OIDC richiede automaticamente i token appropriati usando il codice restituito dall'endpoint di autorizzazione.

oidcOptions.ResponseType = OpenIdConnectResponseType.Code;

MapInboundClaims e la configurazione di NameClaimType e RoleClaimType: molti server OIDC usano "name" e "role" anziché le impostazioni predefinite SOAP/WS-Fed in ClaimTypes. Quando MapInboundClaims è impostato su false, il gestore non esegue i mapping delle attestazioni e i nomi delle attestazioni del token JWT vengono utilizzati direttamente dall'applicazione. L'esempio seguente imposta il tipo di attestazione del ruolo su "roles," che è appropriato per Microsoft Entra ID (ME-ID). Consultare la documentazione del provider di identità per maggiori informazioni.

Nota

MapInboundClaims deve essere impostato su false per la maggior parte dei provider OIDC, che impedisce la ridenominazione delle attestazioni.

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

Configurazione del percorso: i percorsi devono corrispondere all'URI di reindirizzamento (percorso di callback di accesso) e ai percorsi di reindirizzamento post disconnessione (percorso di callback con disconnessione) configurati durante la registrazione dell'applicazione con il provider OIDC. Nel portale di Azure i percorsi vengono configurati nel pannello Autenticazione della registrazione dell'app. Entrambi i percorsi di accesso e disconnessione devono essere registrati come URI di reindirizzamento. I valori predefiniti sono /signin-oidc e /signout-callback-oidc.

CallbackPath: percorso della richiesta all'interno del percorso di base dell'app in cui viene restituito l'agente utente.

Configurare il percorso di callback post-disconnessione nella configurazione della registrazione del provider OIDC per l'app. Nell'esempio seguente il segnaposto {PORT} è la porta dell'app:

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

Nota

Una porta non è necessaria per localhost indirizzi quando si usa Microsoft Entra ID. La maggior parte degli altri provider OIDC richiede la porta corretta.

SignedOutCallbackPath (chiave di configurazione: "SignedOutCallbackPath"): percorso della richiesta all'interno del percorso di base dell'app intercettato dal gestore OIDC in cui l'agente utente viene restituito per la prima volta dopo la disconnessione dal provider di identità. L'app di esempio non imposta un valore per il percorso perché viene usato il valore predefinito "/signout-callback-oidc". Dopo aver intercettato la richiesta, il gestore OIDC reindirizza al SignedOutRedirectUri o RedirectUri, se specificato.

Configurare il percorso di callback post-disconnessione nella configurazione della registrazione del provider OIDC per l'app. Nell'esempio seguente il segnaposto {PORT} è la porta dell'app:

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

Nota

Quando si usa Microsoft Entra ID, impostare il percorso nelle voci URI di reindirizzamento della configurazione della piattaforma Web nel portale Entra o nel portale di Azure. Una porta non è necessaria per gli indirizzi localhost quando si usa Entra. La maggior parte degli altri provider OIDC richiede la porta corretta. Se non si aggiunge l'URI del percorso di callback dopo la disconnessione alla registrazione dell'app in Entra, Entra rifiuta di reindirizzare l'utente all'app e chiede semplicemente all'utente di chiudere la finestra del browser.

RemoteSignOutPath: le richieste ricevute in questo percorso causano il richiamo della disconnessione da parte del gestore tramite lo schema di disconnessione.

Nell'esempio seguente il segnaposto {PORT} è la porta dell'app:

https://localhost/signout-oidc

Nota

Quando si usa Microsoft Entra ID, impostare l'URL di logout del front-channel nel portale di Entra o Azure. Una porta non è necessaria per gli indirizzi localhost quando si usa Entra. La maggior parte degli altri provider OIDC richiede la porta corretta.

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

Esempi (valori predefiniti):

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

(Microsoft Azure solo con l'endpoint "comune")TokenValidationParameters.IssuerValidator: molti provider OIDC funzionano con il validator predefinito dell'emittente, ma è necessario tenere conto dell'emittente parametrizzato con l'ID tenant ({TENANT ID}) restituito da https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration. Per altre informazioni, vedere SecurityTokenInvalidIssuerException con OpenID Connect e l'endpoint "common" di Azure AD (AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet #1731).

Solo per le app che usano Microsoft Entra ID o Azure AD B2C con l'endpoint "comune":

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

Blazor Web App progetto cliente (`BlazorWebAppOidc.Client`)

Il progetto BlazorWebAppOidc.Client è lato cliente di Blazor Web App.

Il client chiama AddAuthenticationStateDeserialization per deserializzare e usare lo stato di autenticazione passato dal server. Lo stato di autenticazione è fisso per la durata dell'applicazione WebAssembly.

La classe PersistentAuthenticationStateProvider (PersistentAuthenticationStateProvider.cs) è un componente lato client AuthenticationStateProvider che determina lo stato di autenticazione dell'utente cercando i dati che sono stati mantenuti nella pagina al momento del rendering sul server. Lo stato di autenticazione è fisso per la durata dell'applicazione WebAssembly.

Se l'utente deve accedere o disconnettersi, è necessario ricaricare una pagina completa.

L'app di esempio fornisce solo un nome utente e un messaggio di posta elettronica a scopo di visualizzazione.

Questa versione dell'articolo illustra l'implementazione di OIDC senza adottare il modello Back-end per front-end (BFF) con un'app che adotta il rendering globale di Interactive Server (singolo progetto). Il modello BFF è utile per effettuare richieste autenticate a servizi esterni. Modificare il selettore della versione dell'articolo in modello BFF se la specifica dell'app richiede l'adozione del modello BFF con il rendering automatico interattivo globale.

Viene adottata la specifica seguente:

Blazor Web App usa la modalità di rendering server con interattività globale.
Questa app è un punto di partenza per qualsiasi flusso di autenticazione OIDC. OIDC viene configurato manualmente nell'app e non si basa su Microsoft Entra ID o pacchetti Web MicrosoftIdentity, né l'app di esempio richiede l'hosting di Microsoft Azure. Tuttavia, l'app di esempio può essere usata con Entra, Microsoft Identity Web e ospitata in Azure.
Aggiornamento automatico non interattivo del token.
Un progetto API Web separato illustra una chiamata API Web sicura per i dati meteo.

Per un'esperienza alternativa con Microsoft Authentication Library per .NET, Microsoft Identity Web e Microsoft Entra ID, vedere Proteggere un ASP.NET Core Blazor Web App con Microsoft Entra ID.

Soluzione di esempio

L'app di esempio è costituita dai progetti seguenti:

BlazorWebAppOidcServer: Blazor Web App progetto sul lato server (rendering globale di Interactive Server).
MinimalApiJwt: API Web back-end con un endpoint API minimo per i dati meteo.

Accedere all'esempio tramite la cartella versione più recente nel Blazor repository degli esempi con il collegamento seguente. L'esempio si trova nella BlazorWebAppOidcServer cartella per .NET 8 o versione successiva.

Visualizzare o scaricare il codice di esempio (come scaricare)

Registrazioni dell'app Microsoft Entra ID

È consigliabile usare registrazioni separate per app e API Web, anche quando le app e le API Web si trovano nella stessa soluzione. Le indicazioni seguenti sono relative all'app BlazorWebAppOidcServer e MinimalApiJwt all'API Web della soluzione di esempio, ma le stesse linee guida si applicano in genere a tutte le registrazioni basate su Entra per le app e le API Web.

Registrare quindi l'app (BlazorWebAppOidcServer) con una configurazione della piattaforma Web e un URI di reindirizzamento di https://localhost/signin-oidc (una porta non è necessaria). L'ID tenant e l'ID client dell'app, insieme all'indirizzo di base dell'API Web, all'URI ID app e al nome dell'ambito meteo, vengono usati per configurare l'app nel file Program . Concedere l'autorizzazione all'API per accedere all'API web in Registrazioni app>Autorizzazioni API. Se la specifica di sicurezza dell'app lo richiede, è possibile concedere all'organizzazione il consenso amministratore per accedere all'API Web. Gli utenti e i gruppi autorizzati vengono assegnati alla registrazione dell'app in Registrazioni app>Applicazioni aziendali.

Altre indicazioni sulla configurazione di Entra per impostazioni specifiche sono disponibili più avanti in questo articolo.

Impostare il segreto del client

Questa sezione si applica solo al progetto server Blazor Web App (BlazorWebAppOidcServer project).

Avviso

Il Blazor progetto server non è stato inizializzato per lo strumento Secret Manager. Usare una shell dei comandi, ad esempio la shell dei comandi di Developer PowerShell in Visual Studio, per eseguire il comando seguente. Prima di eseguire il comando, cambia la directory usando il comando cd per accedere alla directory del progetto server. Il comando stabilisce un identificatore dei segreti utente (<UserSecretsId> nel file di progetto dell'app):

dotnet user-secrets init

Eseguire il comando seguente per impostare il segreto client. Il {SECRET} segnaposto è il segreto client ottenuto dalla registrazione dell'app:

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

Se si usa Visual Studio, è possibile verificare che il segreto sia impostato facendo clic con il pulsante destro del mouse sul progetto in Esplora soluzioni e scegliendo Gestisci segreti utente.

`MinimalApiJwt` progetto

Il MinimalApiJwt progetto è un'API Web back-end per più progetti front-end. Il progetto configura un endpoint API minimo per i dati meteo.

Il progetto crea un endpoint API minimo per i dati meteo:

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

Configurare il progetto nella JwtBearerOptions della chiamata AddJwtBearer nel file Program del progetto.

jwtOptions.Authority = "{AUTHORITY}";

Il formato dell'autorità dipende dal tipo di tenant in uso. Gli esempi seguenti per Microsoft Entra ID usano un ID tenant di aaaabbbb-0000-cccc-1111-dddd2222eeee.

esempio di autorità del tenant ME-ID:

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

Esempio di autorità tenant AAD B2C:

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

Imposta Audience il gruppo di destinatari per qualsiasi token OIDC ricevuto.

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

Nota

ME-ID esempio di URI ID app tenant:

jwtOptions.Audience = "api://11112222-bbbb-3333-cccc-4444dddd5555";

Esempio di URI dell'ID dell'app tenant di AAD B2C:

jwtOptions.Audience = "https://contoso.onmicrosoft.com/11112222-bbbb-3333-cccc-4444dddd5555";

`BlazorWebAppOidcServer` progetto

L'aggiornamento automatico dei token non interattivi viene gestito da un processo di aggiornamento personalizzato cookie (CookieOidcRefresher.cs).

TokenHandler.cs:

public class TokenHandler(IHttpContextAccessor httpContextAccessor) : 
    DelegatingHandler
{
    protected override async Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request, CancellationToken cancellationToken)
    {
        if (httpContextAccessor.HttpContext is null)
        {
            throw new Exception("HttpContext not available");
        }

        var accessToken = await httpContextAccessor.HttpContext
            .GetTokenAsync("access_token");

        request.Headers.Authorization =
            new AuthenticationHeaderValue("Bearer", accessToken);

        return await base.SendAsync(request, cancellationToken);
    }
}

builder.Services.AddScoped<TokenHandler>();

builder.Services.AddHttpClient("ExternalApi",
      client => client.BaseAddress = new Uri(builder.Configuration["ExternalApiUri"] ?? 
          throw new Exception("Missing base address!")))
      .AddHttpMessageHandler<TokenHandler>();

Il Weather componente usa l'attributo per impedire l'accesso [Authorize] non autorizzato. Per altre informazioni su come richiedere l'autorizzazione nell'app tramite un criterio di autorizzazione e rifiutare esplicitamente l'autorizzazione in un subset di endpoint pubblici, vedere le Razor linee guida OIDC per le pagine.

Il ExternalApi client HTTP viene usato per inviare una richiesta di dati meteo all'API Web sicura. OnInitializedAsync di :

using var request = new HttpRequestMessage(HttpMethod.Get, "/weather-forecast");
var client = ClientFactory.CreateClient("ExternalApi");
using var response = await client.SendAsync(request);
response.EnsureSuccessStatusCode();

forecasts = await response.Content.ReadFromJsonAsync<WeatherForecast[]>() ??
    throw new IOException("No weather forecast!");

Nel file del appsettings.json progetto configurare l'URI dell'API esterna:

"ExternalApiUri": "{BASE ADDRESS}"

Esempio:

"ExternalApiUri": "https://localhost:7277"

La seguente configurazione OpenIdConnectOptions è trovata nel file del progetto Program nella chiamata a AddOpenIdConnect:

oidcOptions.PushedAuthorizationBehavior = PushedAuthorizationBehavior.UseIfAvailable;

oidcOptions.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;

oidcOptions.Scope.Add(OpenIdConnectScope.OpenIdProfile);

Configurare l'ambito Weather.Get per accedere all'API web esterna per i dati meteo. L'esempio seguente si basa sull'uso dell'ID Entra in un dominio tenant ME-ID. Nell'esempio seguente il {APP ID URI} segnaposto si trova nel portale entra o di Azure in cui è esposta l'API Web. Per qualsiasi altro provider di identità, usare l'ambito appropriato.

oidcOptions.Scope.Add("{APP ID URI}/Weather.Get");

Il formato dell'ambito dipende dal tipo di tenant in uso. Negli esempi seguenti il dominio tenant è contoso.onmicrosoft.come l'ID client è 11112222-bbbb-3333-cccc-4444dddd5555.

ME-ID esempio di URI ID app tenant:

oidcOptions.Scope.Add("api://11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get");

Esempio di URI dell'ID dell'app tenant di AAD B2C:

oidcOptions.Scope.Add("https://contoso.onmicrosoft.com/11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get");

oidcOptions.SaveTokens = true;

Ambito per l'accesso offline (Scope): l'ambito offline_access è obbligatorio per il token di aggiornamento.

oidcOptions.Scope.Add(OpenIdConnectScope.OfflineAccess);

Authority e ClientId: imposta l'autorità e l'ID client per le chiamate OIDC.

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

L'esempio seguente usa un ID tenant di aaaabbbb-0000-cccc-1111-dddd2222eeee e un ID client di 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";

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

oidcOptions.ResponseType = OpenIdConnectResponseType.Code;

Nota

MapInboundClaims deve essere impostato su false per la maggior parte dei provider OIDC, che impedisce la ridenominazione delle attestazioni.

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

CallbackPath: percorso della richiesta all'interno del percorso di base dell'app in cui viene restituito l'agente utente.

Configurare il percorso di callback post-disconnessione nella configurazione della registrazione del provider OIDC per l'app. Nell'esempio seguente il segnaposto {PORT} è la porta dell'app:

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

Nota

Una porta non è necessaria per localhost indirizzi quando si usa Microsoft Entra ID. La maggior parte degli altri provider OIDC richiede la porta corretta.

Configurare il percorso di callback post-disconnessione nella configurazione della registrazione del provider OIDC per l'app. Nell'esempio seguente il segnaposto {PORT} è la porta dell'app:

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

Nota

RemoteSignOutPath: le richieste ricevute in questo percorso causano il richiamo della disconnessione da parte del gestore tramite lo schema di disconnessione.

Nell'esempio seguente il segnaposto {PORT} è la porta dell'app:

https://localhost/signout-oidc

Nota

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

Esempi (valori predefiniti):

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

Solo per le app che usano Microsoft Entra ID o Azure AD B2C con l'endpoint "comune":

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

Questa versione dell'articolo illustra l'implementazione di OIDC con il modello Back-end per il front-end (BFF). Se le specifiche dell'app non richiedono l'adozione del modello BFF, modifica il selettore della versione dell'articolo in Modello non BFF (Rendering automatico interattivo) o Modello non BFF (Rendering interattivo server).

Prerequisiti

.NET Aspire richiede Visual Studio versione 17.10 o successiva.

Vedere anche la sezione Prerequisiti di Avvio rapido: Creare la prima .NET Aspire app.

Soluzione di esempio

L'app di esempio è costituita dai progetti seguenti:

.NET Aspire:
- Aspire.AppHost: usato per gestire le problematiche di orchestrazione generali dell'app.
- Aspire.ServiceDefaults: contiene configurazioni di app predefinite .NET Aspire che possono essere estese e personalizzate in base alle esigenze.
MinimalApiJwt: API Web back-end contenente un esempio di endpoint API minimo per i dati meteo.
BlazorWebAppOidc: progetto lato server di Blazor Web App. Il progetto utilizza YARP per instradare le richieste mediante un proxy verso un endpoint delle previsioni meteo nel progetto API web di back-end (MinimalApiJwt) con i dati di access_token memorizzati nell'autenticazione cookie.
BlazorWebAppOidc.Client: progetto lato client di Blazor Web App.

Accedere all'esempio tramite la cartella versione più recente nel Blazor repository degli esempi con il collegamento seguente. L'esempio si trova nella BlazorWebAppOidcBff cartella per .NET 8 o versione successiva.

Visualizzare o scaricare il codice di esempio (come scaricare)

Blazor Web App usa la modalità di rendering automatico con interattività globale.

Il progetto server chiama AddAuthenticationStateSerialization per aggiungere un provider di stato di autenticazione lato server che usa PersistentComponentState per trasferire lo stato di autenticazione al client. Il client chiama AddAuthenticationStateDeserialization per deserializzare e usare lo stato di autenticazione passato dal server. Lo stato di autenticazione è fisso per la durata dell'applicazione WebAssembly.

La PersistingAuthenticationStateProvider classe (PersistingAuthenticationStateProvider.cs) è un componente lato AuthenticationStateProvider server che usa PersistentComponentState per trasferire lo stato di autenticazione al client, che viene quindi mantenuto per la durata dell'applicazione WebAssembly.

Questa app è un punto di partenza per qualsiasi flusso di autenticazione OIDC. OIDC viene configurato manualmente nell'app e non si basa su Microsoft Entra ID o pacchetti Web MicrosoftIdentity, né l'app di esempio richiede l'hosting di Microsoft Azure. Tuttavia, l'app di esempio può essere usata con Entra, Microsoft Identity Web e ospitata in Azure.

Rinnovo automatico del token non interattivo con l'aiuto di un aggiornatore personalizzato cookie (CookieOidcRefresher.cs).

Il modello Back-end per front-end (BFF) viene adottato usando .NET Aspire per l'individuazione del servizio e YARP per il proxy delle richieste a un endpoint di previsione meteo nell'app back-end.

L'API Web back-end (MinimalApiJwt) usa l'autenticazione bearer JWT per convalidare i token JWT salvati dal Blazor Web App nella fase di accesso cookie.

Aspire migliora l'esperienza di creazione di app cloud-native .NET. Fornisce un set di strumenti e modelli coerente e con opinioni per la creazione e l'esecuzione di app distribuite.

YARP (Yet Another Reverse Proxy) è una libreria usata per creare un server proxy inverso. MapForwarder Program nel file del progetto server aggiunge l'inoltro diretto delle richieste HTTP che corrispondono al modello specificato a una destinazione specifica usando la configurazione predefinita per la richiesta in uscita, le trasformazioni personalizzate e il client HTTP predefinito:

Quando si esegue il rendering del componente Weather nel server, il componente usa la classe ServerWeatherForecaster per delegare la richiesta di dati meteo con il token di accesso dell'utente. IHttpContextAccessor.HttpContext determina se un HttpContext è disponibile per l'uso dal metodo GetWeatherForecastAsync. Per altre informazioni, vedere ASP.NET Componenti di baseRazor.
Quando viene eseguito il rendering del componente nel client, il componente usa l'implementazione del servizio ClientWeatherForecaster, che utilizza un HttpClient preconfigurato (nel file Program del progetto client) per effettuare una chiamata API Web al progetto server. Un endpoint API minimo (/weather-forecast) definito nel file del Program progetto server trasforma la richiesta con il token di accesso dell'utente per ottenere i dati meteo.

Per altre informazioni su .NET Aspire, vedere Disponibilità generale di .NET Aspire: semplificazione dello sviluppo di .NET Cloud-Native (maggio 2024).

Per altre informazioni sulle chiamate API (Web) usando astrazioni di un servizio in Blazor Web Apps, vedere Chiamare un'API Web da un'app ASP.NET CoreBlazor.

Registrazioni dell'app Microsoft Entra ID

Altre indicazioni sulla configurazione di Entra per impostazioni specifiche sono disponibili più avanti in questo articolo.

Impostare il segreto del client

Questa sezione si applica solo al progetto server Blazor Web App (BlazorWebAppOidc project).

Avviso

dotnet user-secrets init

Eseguire il comando seguente per impostare il segreto client. Il {SECRET} segnaposto è il segreto client ottenuto dalla registrazione dell'app:

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

.NET Aspire progetti

Per ulteriori informazioni sull'uso di e sui dettagli dei progetti e dell'app di esempio, vedere la documentazione .

Verificare di aver soddisfatto i prerequisiti per .NET Aspire. Per altre informazioni, vedere la sezione Prerequisiti di Avvio rapido: Creare la prima .NET Aspire app.

L'app di esempio configura solo un profilo di avvio HTTP non sicuro (http) da usare durante i test di sviluppo. Per altre informazioni, incluso un esempio di profili di impostazioni di avvio non sicure e sicure, vedere Consentire il trasporto non sicuro in .NET Aspire (.NET Aspire documentazione).

`MinimalApiJwt` progetto

Il MinimalApiJwt progetto è un'API Web back-end per più progetti front-end. Il progetto configura un endpoint API minimo per i dati meteo. Le richieste dal Blazor Web App progetto lato server (BlazorWebAppOidc) vengono inviate tramite proxy al MinimalApiJwt progetto.

Un endpoint sicuro dei dati di previsione meteo si trova nel file del Program progetto.

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

Il RequireAuthorization metodo di estensione richiede l'autorizzazione per la definizione di route. Per tutti i controller aggiunti al progetto, aggiungere l'attributo[Authorize] al controller o all'azione.

Configurare il progetto nella JwtBearerOptions della chiamata AddJwtBearer nel file Program del progetto.

jwtOptions.Authority = "{AUTHORITY}";

Il formato dell'autorità dipende dal tipo di tenant in uso. Gli esempi seguenti per Microsoft Entra ID usano un ID tenant di aaaabbbb-0000-cccc-1111-dddd2222eeee.

esempio di autorità del tenant ME-ID:

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

Esempio di autorità tenant AAD B2C:

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

Imposta Audience il gruppo di destinatari per qualsiasi token OIDC ricevuto.

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

Nota

ME-ID esempio di URI ID app tenant:

jwtOptions.Audience = "api://11112222-bbbb-3333-cccc-4444dddd5555";

Esempio di URI dell'ID dell'app tenant di AAD B2C:

jwtOptions.Audience = "https://contoso.onmicrosoft.com/11112222-bbbb-3333-cccc-4444dddd5555";

Progetto lato server Blazor Web App (`BlazorWebAppOidc`)

In questa sezione viene spiegato come configurare il progetto Blazor lato server.

La configurazione seguente OpenIdConnectOptions si trova nel file del progetto Program nella chiamata a AddOpenIdConnect.

oidcOptions.PushedAuthorizationBehavior = PushedAuthorizationBehavior.UseIfAvailable;

oidcOptions.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;

oidcOptions.Scope.Add(OpenIdConnectScope.OpenIdProfile);

SaveTokens: definisce se i token di accesso e aggiornamento devono essere archiviati in AuthenticationProperties dopo un'autorizzazione riuscita. Il valore è impostato su true per autenticare le richieste di dati meteo dal progetto API Web back-end (MinimalApiJwt).

oidcOptions.SaveTokens = true;

Ambito per l'accesso offline (Scope): l'ambito offline_access è obbligatorio per il token di aggiornamento.

oidcOptions.Scope.Add(OpenIdConnectScope.OfflineAccess);

Ambiti per ottenere dati meteo dall'API Web (Scope): configurare l'ambito per l'accesso Weather.Get all'API Web esterna per i dati meteo. Nell'esempio seguente il {APP ID URI} segnaposto si trova nel portale entra o di Azure in cui è esposta l'API Web. Per qualsiasi altro provider di identità, usare l'ambito appropriato.

oidcOptions.Scope.Add("{APP ID URI}/Weather.Get");

Il formato dell'ambito dipende dal tipo di tenant in uso. Negli esempi seguenti il dominio tenant è contoso.onmicrosoft.come l'ID client è 11112222-bbbb-3333-cccc-4444dddd5555.

ME-ID esempio di URI ID app tenant:

oidcOptions.Scope.Add("api://11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get");

Esempio di URI dell'ID dell'app tenant di AAD B2C:

oidcOptions.Scope.Add("https://contoso.onmicrosoft.com/11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get");

Authority e ClientId: imposta l'autorità e l'ID client per le chiamate OIDC.

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

L'esempio seguente usa un ID tenant di aaaabbbb-0000-cccc-1111-dddd2222eeee e un ID client di 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";

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

oidcOptions.ResponseType = OpenIdConnectResponseType.Code;

MapInboundClaims e la configurazione di NameClaimType e RoleClaimType: molti server OIDC usano "name" e "role" anziché le impostazioni predefinite SOAP/WS-Fed in ClaimTypes. Quando MapInboundClaims è impostato su false, il gestore non esegue il mapping delle attestazioni e i nomi delle attestazioni del token JWT vengono direttamente utilizzati dall'app. L'esempio seguente imposta il tipo di attestazione del ruolo su "roles," che è appropriato per Microsoft Entra ID (ME-ID). Consultare la documentazione del provider di identità per maggiori informazioni.

Nota

MapInboundClaims deve essere impostato su false per la maggior parte dei provider OIDC, che impedisce la ridenominazione delle attestazioni.

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

Configurare il percorso di callback post-disconnessione nella configurazione della registrazione del provider OIDC per l'app. Nell'esempio seguente il segnaposto {PORT} è la porta dell'app:

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

Nota

Una porta non è necessaria per localhost indirizzi quando si usa Microsoft Entra ID. La maggior parte degli altri provider OIDC richiede la porta corretta.

Configurare il percorso di callback post-disconnessione nella configurazione della registrazione del provider OIDC per l'app. Nell'esempio seguente il segnaposto {PORT} è la porta dell'app:

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

Nota

RemoteSignOutPath: le richieste ricevute in questo percorso causano il richiamo della disconnessione da parte del gestore tramite lo schema di disconnessione.

Nell'esempio seguente il segnaposto {PORT} è la porta dell'app:

https://localhost/signout-oidc

Nota

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

Esempi (valori predefiniti):

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

Solo per le app che usano Microsoft Entra ID o Azure AD B2C con l'endpoint "comune":

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

Progetto sul lato client Blazor Web App (`BlazorWebAppOidc.Client`)

Il progetto BlazorWebAppOidc.Client è lato cliente di Blazor Web App.

Se l'utente deve accedere o disconnettersi, è necessario ricaricare una pagina completa.

L'app di esempio fornisce solo un nome utente e un messaggio di posta elettronica a scopo di visualizzazione.

Serializzare solo il nome e le attestazioni del ruolo

Questa sezione si applica solo al modello non BFF (Interactive Auto) e al modello BFF (Interactive Auto) e alle app di esempio.

Program Nel file tutte le attestazioni vengono serializzate impostando SerializeAllClaims su true. Se si desidera solo il nome e le attestazioni del ruolo serializzate per CSR, rimuovere l'opzione o impostarla su false.

Fornire la configurazione con il provider di configurazione JSON (impostazioni dell'app)

I progetti di soluzione di esempio configurano l'autenticazione OIDC e l'autenticazione portatore JWT nei loro file Program per rendere individuabili le impostazioni di configurazione usando il completamento automatico di C#. Le app professionali usano in genere un provider di configurazione per configurare le opzioni OIDC, ad esempio il provider di configurazione JSON predefinito. Il provider di configurazione JSON carica la configurazione dai file appsettings.json/appsettings.{ENVIRONMENT}.json di impostazioni dell'applicazione, dove il {ENVIRONMENT} segnaposto è l'ambiente di runtime dell'applicazione. Seguire le indicazioni riportate in questa sezione per usare i file di impostazioni dell'app per la configurazione.

Nel file delle impostazioni dell'app (appsettings.json) del BlazorWebAppOidc progetto o BlazorWebAppOidcServer aggiungere la configurazione JSON seguente:

"Authentication": {
  "Schemes": {
    "MicrosoftOidc": {
      "Authority": "https://login.microsoftonline.com/{TENANT ID (BLAZOR APP)}/v2.0/",
      "ClientId": "{CLIENT ID (BLAZOR APP)}",
      "CallbackPath": "/signin-oidc",
      "SignedOutCallbackPath": "/signout-callback-oidc",
      "RemoteSignOutPath": "/signout-oidc",
      "SignedOutRedirectUri": "/",
      "Scope": [
        "openid",
        "profile",
        "offline_access",
        "{APP ID URI (WEB API)}/Weather.Get"
      ]
    }
  }
},

Aggiornare i segnaposto nella configurazione precedente in modo che corrispondano ai valori usati dall'app nel Program file:

{TENANT ID (BLAZOR APP)}: ID tenant dell'app Blazor .
{CLIENT ID (BLAZOR APP)}: ID client dell'app Blazor .
{APP ID URI (WEB API)}: URI ID app dell'API Web.

L'autorità "comune" (https://login.microsoftonline.com/common/v2.0/) deve essere usata per le app multi-tenant. Per usare l'autorità "comune" per le app a tenant singolo, vedere la sezione Usare l'autorità "comune" per le app a tenant singolo .

Aggiornare tutti gli altri valori nella configurazione precedente in modo che corrispondano ai valori personalizzati/non predefiniti usati nel Program file.

La configurazione viene prelevata automaticamente dal generatore di autenticazione.

Rimuovere le righe seguenti dal Program file:

- oidcOptions.Scope.Add(OpenIdConnectScope.OpenIdProfile);
- oidcOptions.Scope.Add("...");
- oidcOptions.CallbackPath = new PathString("...");
- oidcOptions.SignedOutCallbackPath = new PathString("...");
- oidcOptions.RemoteSignOutPath = new PathString("...");
- oidcOptions.Authority = "...";
- oidcOptions.ClientId = "...";

ConfigureCookieOidc Nel metodo di CookieOidcServiceCollectionExtensions.csrimuovere la riga seguente:

- oidcOptions.Scope.Add(OpenIdConnectScope.OfflineAccess);

Nel progetto MinimalApiJwt, aggiungi la seguente configurazione delle impostazioni dell'applicazione al file appsettings.json.

"Authentication": {
  "Schemes": {
    "Bearer": {
      "Authority": "https://sts.windows.net/{TENANT ID (WEB API)}/",
      "ValidAudiences": [ "{APP ID URI (WEB API)}" ]
    }
  }
},

Aggiornare i segnaposto nella configurazione precedente in modo che corrispondano ai valori usati dall'app nel Program file:

{TENANT ID (WEB API)}: Tenant ID dell'API web.
{APP ID URI (WEB API)}: URI ID app dell'API Web.

I formati di autorità adottano i seguenti schemi:

ME-ID tipo di tenant: https://sts.windows.net/{TENANT ID}/
Tipo di tenant B2C: https://login.microsoftonline.com/{TENANT ID}/v2.0/

I formati di destinatari adottano i modelli seguenti ({CLIENT ID} è l'ID client dell'API Web; {DIRECTORY NAME} è il nome della directory, ad esempio ): contoso

ME-ID tipo di tenant: api://{CLIENT ID}
Tipo di tenant B2C: https://{DIRECTORY NAME}.onmicrosoft.com/{CLIENT ID}

La configurazione viene acquisita automaticamente dal builder di autenticazione JWT bearer.

Rimuovere le righe seguenti dal Program file:

- jwtOptions.Authority = "...";
- jwtOptions.Audience = "...";

Per altre informazioni sulla configurazione, vedere le risorse seguenti:

Usare l'autorità "comune" per le app a tenant singolo

È possibile usare l'autorità "comune" per le app a tenant singolo, ma è necessario seguire questa procedura per implementare un validator di autorità di certificazione personalizzato.

Aggiungere il Microsoft.IdentityModel.Validators pacchetto NuGet al BlazorWebAppOidc, BlazorWebAppOidcServer, o BlazorWebAppOidcBff progetto.

Nota

Per indicazioni sull'aggiunta di pacchetti alle app .NET, vedere gli articoli sotto Installare e gestire pacchetti in Flusso di lavoro dell'utilizzo di pacchetti (documentazione di NuGet). Verificare le versioni corrette dei pacchetti in NuGet.org.

Nella parte superiore del Program file rendere disponibile lo Microsoft.IdentityModel.Validators spazio dei nomi:

using Microsoft.IdentityModel.Validators;

Usare il codice seguente nel file Program nel quale sono configurate le opzioni OIDC.

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

Per altre informazioni, vedere SecurityTokenInvalidIssuerException con OpenID Connect e l'endpoint "common" di Azure AD (AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet #1731).

Reindirizzare alla home page alla disconnessione

Il componente LogInOrOut (Layout/LogInOrOut.razor) imposta un campo nascosto per l'URL restituito (ReturnUrl) sull'URL corrente (currentURL). Quando l'utente si disconnette dall'app, il provider di identità restituisce l'utente alla pagina da cui si è disconnesso. Se l'utente si disconnette da una pagina sicura, viene restituito alla stessa pagina protetta e inviato tramite il processo di autenticazione. Questo flusso di autenticazione è ragionevole quando gli utenti devono modificare regolarmente gli account.

In alternativa, usare il seguente componente LogInOrOut, che non fornisce un URL di ritorno durante la disconnessione.

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
                </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>

Aggiornamento del token

L'aggiornamento personalizzato cookie (CookieOidcRefresher.cs) aggiorna automaticamente le attestazioni dell'utente al termine della loro validità. L'implementazione corrente prevede di ricevere un token ID dall'endpoint del token in cambio del token di aggiornamento. Le dichiarazioni contenute in questo token ID vengono quindi utilizzate per sovrascrivere le dichiarazioni dell'utente.

L'implementazione di esempio non include il codice per richiedere attestazioni dall'endpoint UserInfo all'aggiornamento del token. Per altre informazioni, vedere BlazorWebAppOidc AddOpenIdConnect with GetClaimsFromUserInfoEndpoint = true doesn't propogate [sic] role claims to client (dotnet/aspnetcore #58826).

Nota

Alcuni provider di identità restituiscono un token di accesso solo quando si usa un token di aggiornamento. Il CookieOidcRefresher può essere aggiornato con logica aggiuntiva per continuare a usare il precedente set di richieste archiviato nell'autenticazione cookie o usare il token di accesso per richiedere informazioni dall'endpoint UserInfo.

Nonce crittografico

Un nonce è un valore stringa che associa la sessione di un client a un token ID per attenuare gli attacchi di riproduzione.

Se ricevi un errore nonce durante lo sviluppo e il collaudo dell'autenticazione, usa una nuova sessione del browser InPrivate/incognito per ogni esecuzione di test, indipendentemente da quanto piccola sia la modifica apportata all'app o all'utente di test perché i dati obsoleti cookie possono causare un errore nonce. Per altre informazioni, vedere la sezione Cookie e dati del sito .

Un nonce non è necessario né ne viene fatto uso quando un token di aggiornamento viene scambiato per un nuovo token di accesso. Nell'app di esempio, CookieOidcRefresher (CookieOidcRefresher.cs) imposta deliberatamente OpenIdConnectProtocolValidator.RequireNonce su false.

I ruoli dell'applicazione per le app non registrate presso Microsoft Entra (ME-ID)

Questa sezione riguarda le app che non usano Microsoft Entra ID (ME-ID) come provider di identità. Per le app registrate con ME-ID, vedere la sezione Ruoli applicazione per le app registrate con Microsoft Entra (ME-ID).

Configurare il tipo di dichiarazione del ruolo (TokenValidationParameters.RoleClaimType) in OpenIdConnectOptions di Program.cs:

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

Per molti fornitori di identità OIDC, il tipo di attestazione del ruolo è role. Controlla la documentazione del provider di identità per il valore corretto.

Sostituire la UserInfo classe nel BlazorWebAppOidc.Client progetto con la classe seguente.

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.");
}

A questo punto, Razor i componenti possono adottare l'autorizzazione basata sui ruoli e basata su criteri. I ruoli dell'applicazione vengono visualizzati nelle role attestazioni, un'attestazione per ogni ruolo.

Ruoli delle applicazioni per le app registrate con Microsoft Entra (ME-ID)

Usare le indicazioni riportate in questa sezione per implementare ruoli applicazione, ME-ID gruppi di sicurezza e ME-ID ruoli di amministratore predefiniti per le app che usano Microsoft Entra ID (ME-ID).

L'approccio descritto in questa sezione configura ME-ID per inviare gruppi e ruoli nell'intestazione di autenticazione cookie . Quando gli utenti sono solo membri di alcuni gruppi di sicurezza e ruoli, l'approccio seguente dovrebbe funzionare per la maggior parte delle piattaforme di hosting senza riscontrare un problema per cui le intestazioni sono troppo lunghe, ad esempio con l'hosting IIS con un limite di lunghezza dell'intestazione predefinito di 16 KB (MaxRequestBytes). Se la lunghezza dell'intestazione è un problema dovuto all'appartenenza a gruppi o ruoli elevati, è consigliabile non seguire le indicazioni riportate in questa sezione a favore dell'implementazione di Microsoft Graph per ottenere i gruppi e i ruoli di un utente da ME-ID separatamente, un approccio che non gonfia le dimensioni dell'autenticazione cookie. Per altre informazioni, vedere Richiesta non valida - Richiesta troppo lunga - Server IIS (dotnet/aspnetcore #57545)..

Configurare il tipo di rivendicazione del ruolo (TokenValidationParameters.RoleClaimType) in OpenIdConnectOptions di Program.cs. Impostare il valore su roles:

oidcOptions.TokenValidationParameters.RoleClaimType = "roles";

Anche se non è possibile assegnare ruoli a gruppi senza un account Premium ME-ID, è possibile assegnare ruoli agli utenti e ricevere attestazioni di ruolo per gli utenti con un account Azure standard. Le indicazioni contenute in questa sezione non richiedono un account ME-ID Premium.

Quando si usa la directory predefinita, seguire le indicazioni riportate in Aggiungere ruoli dell'app all'applicazione e riceverli nel token (ME-ID documentazione) per configurare e assegnare ruoli. Se non si usa la directory predefinita, modificare il manifesto dell'app nel portale di Azure per stabilire manualmente i ruoli dell'app nella appRoles voce del file manifesto. Per altre informazioni, vedere Configurare il claim di ruolo (ME-ID documentazione).

I gruppi di sicurezza di Azure di un utente arrivano nelle groups attestazioni e le assegnazioni di ruolo di amministratore ME-ID integrate arrivano in ID ben noti (wids) nelle attestazioni. I valori per entrambi i tipi di attestazione sono GUID (Identificatori Globali Unici). Quando vengono ricevute dall'app, queste attestazioni possono essere usate per stabilire l'autorizzazione di ruoli e criteri nei Razor componenti.

Nel manifesto dell'app nel portale di Azure impostare l'attributogroupMembershipClaims su All. Un valore di All risulta nell'invio da parte di ME-ID di tutti i gruppi di sicurezza/distribuzione (groups attestazioni) e ruoli (wids attestazioni) dell'utente connesso. Per impostare l'attributo groupMembershipClaims :

Aprire la registrazione dell'app nel portale di Azure.
Selezionare Gestisci>Manifest nella barra laterale.
Trovare l'attributo groupMembershipClaims .
Impostare il valore su All ("groupMembershipClaims": "All").
Selezionare il pulsante Salva .

Sostituire la UserInfo classe nel BlazorWebAppOidc.Client progetto con la classe seguente.

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.");
}

A questo punto, Razor i componenti possono adottare l'autorizzazione basata sui ruoli e basata su criteri:

I ruoli dell'applicazione vengono visualizzati nelle roles attestazioni, un'attestazione per ogni ruolo.
I gruppi di sicurezza appaiono nelle groups attestazioni, ciascuna attestazione per gruppo. I GUID del gruppo di sicurezza vengono visualizzati nel portale di Azure quando si crea un gruppo di sicurezza e vengono elencati quando si seleziona Identity>Panoramica>Gruppi>visualizza.
I ruoli di amministratore ME-ID predefiniti vengono visualizzati nelle attestazioni wids, una per ogni ruolo. L'attestazione wids con un valore di b79fbf4d-3ef9-4689-8143-76b194e85509 viene sempre inviata da ME-ID per gli account non guest del tenant e non fa riferimento a un ruolo di amministratore. I GUID dei ruoli di amministratore (ID modello di ruolo) vengono visualizzati nel portale di Azure quando si seleziona Ruoli e amministratori, seguiti dai puntini di sospensione (...) >Descrizione per il ruolo elencato. Gli ID modello di ruolo sono anche elencati in Ruoli Predefiniti Di Microsoft Entra (documentazione Entra).

Risoluzione dei problemi

Registrazione

L'app server è un'app standard ASP.NET Core. Per abilitare un livello di registrazione inferiore nell'app server, vedere le linee guida per la registrazione di ASP.NET Core.

Per abilitare la registrazione di debug o traccia per Blazor WebAssembly l'autenticazione, vedere la sezione Registrazione dell'autenticazione lato client di ASP.NET Core Blazor con il selettore della versione dell'articolo impostato su ASP.NET Core in .NET 7 o versione successiva.

Errori comuni

Il debugger si interrompe in caso di eccezione durante la disconnessione con Microsoft Entra External ID

L'eccezione seguente interrompe il debugger di Visual Studio durante il logout con Microsoft Entra External ID:

Uncaught TypeError TypeError: Failed to execute 'postMessage' on 'Window': The provided value cannot be converted to a sequence.

L'eccezione viene generata dal codice JavaScript Entra, quindi questo non è un problema con ASP.NET Core. L'eccezione non influisce sulle funzionalità dell'app nell'ambiente di produzione, quindi l'eccezione può essere ignorata durante i test di sviluppo locali.
Configurazione errata dell'app o Identity del provider (IP)

Gli errori più comuni sono causati da una configurazione errata. Di seguito sono riportati alcuni esempi:
- A seconda dei requisiti dello scenario, un'autorità mancante o non corretta, istanza, ID tenant, dominio tenant, ID client o URI di reindirizzamento impedisce a un'app di autenticare i client.
- Gli ambiti di richiesta non corretti impediscono ai client di accedere agli endpoint DELL'API Web del server.
- Autorizzazioni DELL'API server non corrette o mancanti impediscono ai client di accedere agli endpoint DELL'API Web del server.
- L'esecuzione dell'app su una porta diversa da quella configurata nell'URI di reindirizzamento della registrazione dell'app IP. Si noti che non è necessaria una porta per Microsoft Entra ID e per un'app che gira su un indirizzo di test di sviluppo localhost, ma la configurazione della porta dell'app e la porta su cui l'app è in funzione devono corrispondere per gli indirizzi non-localhost.
La panoramica della configurazione in questo articolo mostra esempi di configurazione corretta. Controllare attentamente la configurazione alla ricerca di errori di configurazione di app e IP.

Se la configurazione è corretta:
- Analizzare i log delle applicazioni.
- Esaminare il traffico di rete tra l'app client e l'app IP o server con gli strumenti di sviluppo del browser. Spesso, un messaggio di errore esatto o un messaggio con un indizio sulla causa del problema viene restituito al client dall'app IP o server dopo aver effettuato una richiesta. La guida agli strumenti di sviluppo si trova negli articoli seguenti:
  - Google Chrome (documentazione di Google)
  - Microsoft Edge
  - Mozilla Firefox (documentazione di Mozilla)
Il team della documentazione risponde al feedback e ai bug dei documenti negli articoli (aprire un problema dalla sezione Commenti e suggerimenti della pagina ), ma non è in grado di fornire supporto tecnico. Sono disponibili diversi forum di supporto pubblico per facilitare la risoluzione dei problemi di un'app. Consigliamo quanto segue:
I forum precedenti non sono di proprietà o controllati da Microsoft.

Per i report sui bug riproducibili del framework che non riguardano la sicurezza, che non sono sensibili e non sono riservati, aprire un problema con l'unità del prodotto ASP.NET Core. Non aprire un problema con l'unità di prodotto fino a quando non hai approfondito la causa di un problema e non puoi risolverlo autonomamente e con l'aiuto della community in un forum di supporto pubblico. L'unità prodotto non è in grado di risolvere i problemi relativi alle singole app interrotte a causa di semplici errori di configurazione o casi d'uso che coinvolgono servizi di terze parti. Se un report è sensibile o riservato in natura o descrive un potenziale difetto di sicurezza nel prodotto che potrebbero sfruttare i cyberattacker, vedere Segnalazione di problemi e bug di sicurezza (dotnet/aspnetcorerepository GitHub).
Client non autorizzato per ME-ID

info: Microsoft.AspNetCore.Authorization.DefaultAuthorizationService[2] Autorizzazione non riuscita. Questi requisiti non sono stati soddisfatti: DenyAnonymousAuthorizationRequirement: richiede un utente autenticato.

Errore di callback durante l'accesso da ME-ID:
- Errore: unauthorized_client
- Description (Descrizione): AADB2C90058: The provided application is not configured to allow public clients.
Per risolvere l'errore:
1. Nel portale di Azure accedere al manifesto dell'app.
2. Impostare l'attributoallowPublicClient su null o true.

Cookie e dati del sito

I cookie e i dati del sito possono persistere tra gli aggiornamenti delle app e interferire con i test e la risoluzione dei problemi. Cancellare quanto segue quando si apportano modifiche al codice dell'app, modifiche all'account utente con il provider o modifiche alla configurazione dell'app del provider:

Cookie di accesso utente
Cookie dell'app
Dati del sito memorizzati nella cache e archiviati

Un approccio per evitare che i cookie e i dati del sito persistenti interferiscano con i test e la risoluzione dei problemi consiste nel:

Configurare un browser
- Usare un browser per i test che è possibile configurare per cancellare tutti i cookie dati del sito ogni volta che il browser viene chiuso.
- Assicurarsi che il browser venga chiuso manualmente o dall'IDE per qualsiasi modifica apportata alla configurazione dell'app, dell'utente di test o del provider.
Usare un comando personalizzato per aprire un browser in modalità InPrivate o In incognito in Visual Studio:
- Aprire la finestra di dialogo Sfoglia con dal pulsante Esegui di Visual Studio.
- Selezionare il pulsante Aggiungi .
- Specificare il percorso del browser nel campo Programma . I percorsi eseguibili seguenti sono percorsi di installazione tipici per Windows 10. Se il browser è installato in un percorso diverso o non si usa Windows 10, specificare il percorso dell'eseguibile del 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
- Nel campo Argomenti specificare l'opzione della riga di comando usata dal browser per aprire in modalità InPrivate o Incognito. Alcuni browser richiedono l'URL dell'app.
  - Microsoft Edge: usare -inprivate.
  - Google Chrome: usare --incognito --new-window {URL}, dove il {URL} segnaposto è l'URL da aprire (ad esempio, https://localhost:5001).
  - Mozilla Firefox: usare -private -url {URL}, dove il {URL} segnaposto è l'URL da aprire (ad esempio, https://localhost:5001).
- Fornisci un nome nel campo Friendly name. Ad esempio: Firefox Auth Testing.
- Selezionare il pulsante OK .
- Per evitare di dover selezionare il profilo del browser per ogni iterazione di test con un'app, impostare il profilo come predefinito con il pulsante Imposta come predefinito .
- Assicurarsi che il browser sia chiuso dall'IDE per qualsiasi modifica apportata all'app, all'utente di test o alla configurazione del provider.

Aggiornamenti di app

Un'app funzionante potrebbe smettere di funzionare subito dopo l'aggiornamento del .NET Core SDK sulla macchina di sviluppo o la modifica delle versioni dei pacchetti all'interno dell'app. In alcuni casi i pacchetti incoerenti possono interrompere un'app quando si eseguono aggiornamenti principali. La maggior parte di questi problemi può essere risolta attenendosi alle istruzioni seguenti:

Cancellare le cache dei pacchetti NuGet del sistema locale eseguendo dotnet nuget locals all --clear da una shell dei comandi.
Eliminare le cartelle bin e obj del progetto.
Ripristinare e ricompilare il progetto.
Eliminare tutti i file nella cartella di distribuzione nel server prima di ridistribuire l'app.

Nota

L'uso di versioni del pacchetto incompatibili con il framework di destinazione dell'app non è supportato. Per informazioni su un pacchetto, usare la raccolta NuGet.

Avviare la soluzione dal progetto corretto

Blazor Web App:

Per uno degli esempi del modello Backend-for-Frontend (BFF), avviare la soluzione dal progetto Aspire/Aspire.AppHost.
Per uno degli esempi di modelli non BFF, avviare la soluzione dal progetto server.

Blazor Server:

Avviare la soluzione dal progetto server.

Esaminare l'utente

Il componente seguente UserClaims può essere usato direttamente nelle app o funge da base per un'ulteriore personalizzazione.

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

Risorse aggiuntive

AzureAD/microsoft-identity-web Repository GitHub: indicazioni utili sull'implementazione di Microsoft Identity Web per Microsoft Entra ID e Azure Active Directory B2C per le app ASP.NET Core, inclusi collegamenti ad app di esempio e documentazione di Azure correlata. Attualmente, Blazor Web Apps non vengono affrontati in modo esplicito dalla documentazione di Azure, ma l'installazione e la configurazione di un Blazor Web App per il ME-ID e l'hosting Azure è equivalente a qualsiasi app Web ASP.NET Core.
AuthenticationStateProvider servizio
Gestire lo stato di autenticazione in Blazor Web Apps
Aggiornare il token durante la richiesta HTTP in Blazor Interactive Server con OIDC (dotnet/aspnetcore #55213)
Proteggi i dati in Blazor Web Apps con il rendering automatico interattivo
Come accedere a un oggetto AuthenticationStateProvider da un oggetto DelegatingHandler

Condividi tramite

Proteggere un ASP.NET Core Blazor Web App con OpenID Connect (OIDC)

Soluzione di esempio

Registrazioni dell'app Microsoft Entra ID

Impostare il segreto del client

MinimalApiJwt progetto

Blazor Web App progetto server (BlazorWebAppOidc)

Blazor Web App progetto cliente (BlazorWebAppOidc.Client)

Soluzione di esempio

Registrazioni dell'app Microsoft Entra ID

Impostare il segreto del client

MinimalApiJwt progetto

BlazorWebAppOidcServer progetto

Prerequisiti

Soluzione di esempio

Registrazioni dell'app Microsoft Entra ID

Impostare il segreto del client

.NET Aspire progetti

MinimalApiJwt progetto

Progetto lato server Blazor Web App (BlazorWebAppOidc)

Progetto sul lato client Blazor Web App (BlazorWebAppOidc.Client)

Serializzare solo il nome e le attestazioni del ruolo

Fornire la configurazione con il provider di configurazione JSON (impostazioni dell'app)

Usare l'autorità "comune" per le app a tenant singolo

Reindirizzare alla home page alla disconnessione

Aggiornamento del token

Nonce crittografico

I ruoli dell'applicazione per le app non registrate presso Microsoft Entra (ME-ID)

Ruoli delle applicazioni per le app registrate con Microsoft Entra (ME-ID)

Risoluzione dei problemi

Registrazione

Errori comuni

Cookie e dati del sito

Aggiornamenti di app

Avviare la soluzione dal progetto corretto

Esaminare l'utente

Risorse aggiuntive

Risorse aggiuntive

`MinimalApiJwt` progetto

Blazor Web App progetto server (`BlazorWebAppOidc`)

Blazor Web App progetto cliente (`BlazorWebAppOidc.Client`)

`MinimalApiJwt` progetto

`BlazorWebAppOidcServer` progetto

`MinimalApiJwt` progetto

Progetto lato server Blazor Web App (`BlazorWebAppOidc`)

Progetto sul lato client Blazor Web App (`BlazorWebAppOidc.Client`)