Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo descrive come proteggere un Blazor Web App con Microsoft Identity Platform utilizzando i pacchetti Web di Identity per Microsoft Entra ID con un'app di esempio.
Questa versione dell'articolo illustra l'implementazione di Entra senza adottare il modello Back-end per front-end (BFF). 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.
La specifica seguente è coperta:
-
Blazor Web App usa la modalità di rendering automatico con interattività globale (
InteractiveAuto). - 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.
- L'app utilizza Microsoft Entra ID, basato su package Web di Identity.
- L'aggiornamento automatico dei token non interattivi viene gestito dal framework.
- L'app usa astrazioni del servizio lato server e lato client per visualizzare i dati meteo generati:
- Quando si esegue il rendering del componente
Weatherper visualizzare i dati meteo sul server, il componente utilizza ilServerWeatherForecaster. I pacchetti Web Microsoft Identity forniscono API per creare un servizio Web downstream denominato per effettuare chiamate API Web. IDownstreamApi viene inserito inServerWeatherForecaster, che viene usato per chiamare CallApiForUserAsync per ottenere dati meteo da un'API Web esterna (MinimalApiJwtprogetto). - Quando il componente
Weatherviene renderizzato sul client, utilizza l'implementazione del servizioClientWeatherForecaster, che utilizza un HttpClient preconfigurato (nel fileProgramdel progetto client) per effettuare una chiamata API Web all'API minima del progetto server (/weather-forecast) per ottenere i dati meteo. L'endpoint API minimo ottiene i dati meteo dallaServerWeatherForecasterclasse e lo restituisce al client per il rendering dal componente.
- Quando si esegue il rendering del componente
Soluzione di esempio
La soluzione di esempio è costituita dai progetti seguenti:
-
BlazorWebAppEntra: progetto lato server di Blazor Web App, contenente un esempio endpoint API minimo per i dati meteo. -
BlazorWebAppEntra.Client: Progetto client-side di Blazor Web App. -
MinimalApiJwt: API Web back-end contenente un esempio di 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 BlazorWebAppEntra cartella per .NET 9 o versione successiva.
Avviare la soluzione dal Aspire/Aspire.AppHost progetto.
Visualizzare o scaricare il codice di esempio (procedura per il download)
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 BlazorWebAppEntra 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 (BlazorWebAppEntra) con una configurazione della piattaforma Web con due voci in URI di reindirizzamento: https://localhost/signin-oidc e https://localhost/signout-callback-oidc (le porte non sono necessarie in questi URI). Impostare l'URL di logout del front-channel su https://localhost/signout-callback-oidc (non è necessaria una porta). L'ID tenant, il dominio 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 appsettings.json . 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.
Progetto server Blazor Web App lato (BlazorWebAppEntra)
Il progetto BlazorWebAppEntra è il progetto lato server di Blazor Web App.
Progetto lato utente Blazor Web App (BlazorWebAppEntra.Client)
Il progetto BlazorWebAppEntra.Client rappresenta la parte lato client di Blazor Web App.
Se l'utente deve accedere o disconnettersi durante il rendering lato client, viene avviato un ricaricamento di pagina completo.
Progetto API Web per il back-end (MinimalApiJwt)
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 tenga presente che il progetto MinimalApiJwt deve essere in esecuzione per testare l'endpoint, e l'endpoint è incorporato nel codice del file. Per altre informazioni, vedere Usare file .http in Visual Studio 2022.
Il progetto include pacchetti e configurazione per produrre documenti OpenAPI.
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 API Web backend (MinimalApiJwt)
Configurare il progetto nella classe JwtBearerOptions della AddJwtBearer chiamata nel MinimalApiJwt file del Program progetto.
Per la registrazione dell'app per le API Web, l'ambito Weather.Get viene configurato nel portale entra o di Azure in Esporre un'API.
Authority imposta l'Autorità per effettuare chiamate OIDC.
jwtOptions.Authority = "{AUTHORITY}";
Gli esempi seguenti usano un ID tenant di aaaabbbb-0000-cccc-1111-dddd2222eeee e un nome di contoso directory.
Se l'app è registrata in un tenant ME-ID, l'autorità deve corrispondere all'issuer (iss) del token JWT restituito dal provider di identità.
jwtOptions.Authority = "https://sts.windows.net/aaaabbbb-0000-cccc-1111-dddd2222eeee";
Se l'app è registrata in un tenant di MICROSOFT Entra External ID:
jwtOptions.Authority = "https://contoso.ciamlogin.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0";
Se l'app è registrata in un tenant AAD B2C:
jwtOptions.Authority = "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0";
Note
Azure Active Directory B2C non è più disponibile come servizio ai nuovi clienti a partire dal 1° maggio 2025. I tenant di AAD B2C sono supportati per i clienti con account stabiliti prima del 1° maggio 2025 fino al 2030. Per altre informazioni, vedere Azure AD B2C: Domande frequenti.
Audience imposta il gruppo di destinatari per qualsiasi token di accesso JWT ricevuto.
jwtOptions.Audience = "{AUDIENCE}";
Trova solo il valore corrispondente al percorso dell'URI ID applicazione configurato quando aggiungi l'ambito sotto Weather.Get nel portale Entra o Azure. Non includere il nome dell'ambito "Weather.Get" nel valore.
Negli esempi seguenti viene usato un ID applicazione (client) di 11112222-bbbb-3333-cccc-4444dddd5555. Il terzo esempio usa un dominio tenant di contoso.onmicrosoft.com.
esempio di tenant ME-ID:
jwtOptions.Audience = "api://11112222-bbbb-3333-cccc-4444dddd5555";
Tenant ID esterno di Microsoft Entra
jwtOptions.Audience = "11112222-bbbb-3333-cccc-4444dddd5555";
Esempio di tenant per AAD B2C:
jwtOptions.Audience = "https://contoso.onmicrosoft.com/11112222-bbbb-3333-cccc-4444dddd5555";
Configurare il progetto server (BlazorWebAppEntra)
AddMicrosoftIdentityWebApp da Microsoft Identity Web (Microsoft.Identity.Web pacchetto NuGet, documentazione dell'API) è configurato nel BlazorWebAppEntra file del Program progetto.
Accedere all'ID applicazione (client), al dominio tenant (publisher) e all'ID directory (tenant) dalla registrazione dell'app nel portale Entra o di Azure. L'URI ID app viene ottenuto per l'ambito Weather.Get dalla registrazione dell'API Web. Non includere il nome dell'ambito quando si preleva l'URI ID app dal portale.
La configurazione di autenticazione dipende dal tipo di tenant:
configurazione del tenant ME-ID
Questa sezione si applica a un'app registrata in un tenant Microsoft Entra ID o Azure AAD B2C.
Nel file BlazorWebAppEntra del progetto Program, specificare i valori per i seguenti segnaposto nella configurazione Web di MicrosoftIdentity.
builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
.AddMicrosoftIdentityWebApp(msIdentityOptions =>
{
msIdentityOptions.CallbackPath = "/signin-oidc";
msIdentityOptions.ClientId = "{CLIENT ID (BLAZOR APP)}";
msIdentityOptions.Domain = "{DIRECTORY NAME}.onmicrosoft.com";
msIdentityOptions.Instance = "https://login.microsoftonline.com/";
msIdentityOptions.ResponseType = "code";
msIdentityOptions.TenantId = "{TENANT ID}";
})
.EnableTokenAcquisitionToCallDownstreamApi()
.AddDownstreamApi("DownstreamApi", configOptions =>
{
configOptions.BaseUrl = "{BASE ADDRESS}";
configOptions.Scopes = ["{APP ID URI}/Weather.Get"];
})
.AddDistributedTokenCaches();
Segnaposto nella configurazione precedente:
-
{CLIENT ID (BLAZOR APP)}: ID dell'applicazione (client). -
{DIRECTORY NAME}: nome della directory del dominio tenant (server di pubblicazione). -
{TENANT ID}: ID del tenant della directory. -
{BASE ADDRESS}: indirizzo di base dell'API Web. -
{APP ID URI}: URI dell'ID app per gli ambiti dell'API web. Viene usato uno dei formati seguenti, dove il segnaposto{CLIENT ID (WEB API)}è il Client Id della registrazione Entra dell'API Web e il segnaposto{DIRECTORY NAME}è il nome della directory del dominio del tenant (ad esempio:contoso).- ME-ID formato del tenant:
api://{CLIENT ID (WEB API)} - Formato tenant B2C:
https://{DIRECTORY NAME}.onmicrosoft.com/{CLIENT ID (WEB API)}
- ME-ID formato del tenant:
Example:
builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
.AddMicrosoftIdentityWebApp(msIdentityOptions =>
{
msIdentityOptions.CallbackPath = "/signin-oidc";
msIdentityOptions.ClientId = "00001111-aaaa-2222-bbbb-3333cccc4444";
msIdentityOptions.Domain = "contoso.onmicrosoft.com";
msIdentityOptions.Instance = "https://login.microsoftonline.com/";
msIdentityOptions.ResponseType = "code";
msIdentityOptions.TenantId = "aaaabbbb-0000-cccc-1111-dddd2222eeee";
})
.EnableTokenAcquisitionToCallDownstreamApi()
.AddDownstreamApi("DownstreamApi", configOptions =>
{
configOptions.BaseUrl = "https://localhost:7277";
configOptions.Scopes = ["api://11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get"];
})
.AddDistributedTokenCaches();
Configurazione di Microsoft Entra External ID
Questa sezione si applica a un'app registrata in un tenant di MICROSOFT Entra External ID.
Nel file BlazorWebAppEntra del progetto Program, specificare i valori per i seguenti segnaposto nella configurazione Web di MicrosoftIdentity.
builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
.AddMicrosoftIdentityWebApp(msIdentityOptions =>
{
msIdentityOptions.CallbackPath = "/signin-oidc";
msIdentityOptions.Authority = "https://{DIRECTORY NAME}.ciamlogin.com/{TENANT ID}/v2.0";
msIdentityOptions.ClientId = "{CLIENT ID (BLAZOR APP)}";
msIdentityOptions.ResponseType = "code";
})
.EnableTokenAcquisitionToCallDownstreamApi()
.AddDownstreamApi("DownstreamApi", configOptions =>
{
configOptions.BaseUrl = "{BASE ADDRESS}";
configOptions.Scopes = ["{APP ID URI}/Weather.Get"];
})
.AddDistributedTokenCaches();
Segnaposto nella configurazione precedente:
-
{DIRECTORY NAME}: nome della directory del dominio tenant (server di pubblicazione). -
{CLIENT ID (BLAZOR APP)}: ID dell'applicazione (client). -
{BASE ADDRESS}: indirizzo di base dell'API Web. -
{APP ID URI}: URI dell'ID app per gli ambiti dell'API web. Vengono utilizzati i formati seguenti, in cui il{CLIENT ID (WEB API)}segnaposto è l'ID client della registrazione Entra dell'API web e il{DIRECTORY NAME}segnaposto è il nome della directory del dominio del tenant (editore) (ad esempio:contoso).- ME-ID o formato tenant ID esterno di Microsoft Entra:
api://{CLIENT ID (WEB API)} - Formato tenant B2C:
https://{DIRECTORY NAME}.onmicrosoft.com/{CLIENT ID (WEB API)}
- ME-ID o formato tenant ID esterno di Microsoft Entra:
Example:
builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
.AddMicrosoftIdentityWebApp(msIdentityOptions =>
{
msIdentityOptions.CallbackPath = "/signin-oidc";
msIdentityOptions.Authority = "https://contoso.ciamlogin.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0";
msIdentityOptions.ClientId = "00001111-aaaa-2222-bbbb-3333cccc4444";
msIdentityOptions.ResponseType = "code";
})
.EnableTokenAcquisitionToCallDownstreamApi()
.AddDownstreamApi("DownstreamApi", configOptions =>
{
configOptions.BaseUrl = "https://localhost:7277";
configOptions.Scopes = ["api://11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get"];
})
.AddDistributedTokenCaches();
Il percorso di callback (CallbackPath) deve corrispondere all'URI di reindirizzamento (percorso di callback di accesso) configurato durante la registrazione dell'applicazione in Entra o portale di Azure. I percorsi vengono configurati nel pannello Autenticazione della registrazione dell'app. Il valore predefinito di CallbackPath è /signin-oidc per un URI di reindirizzamento registrato di https://localhost/signin-oidc (non è necessaria una porta).
SignedOutCallbackPath è il percorso della richiesta all'interno del percorso di base dell'app intercettato dal gestore OpenID Connect in cui l'agente utente viene restituito per la prima volta dopo la disconnessione da Entra. 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 OpenID Connect reindirizza al SignedOutRedirectUri o RedirectUri, se specificato.
Warning
Non archiviare segreti dell'app, stringa 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.
Questa versione dell'articolo illustra l'implementazione di Entra con il modello Back-end per front-end (BFF). Modificare il selettore della versione dell'articolo impostandolo su Modello non BFF se la specifica dell'app non richiede l'adozione del modello BFF.
La specifica seguente è coperta:
-
Blazor Web App usa la modalità di rendering automatico con interattività globale (
InteractiveAuto). - 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.
- L'app utilizza Microsoft Entra ID, basato su package Web di Identity.
- L'aggiornamento automatico dei token non interattivi viene gestito dal framework.
- Il modello Back-End per Front-End (BFF) viene adottato utilizzando Aspire per la scoperta del servizio e YARP per il proxy delle richieste verso un endpoint di previsione meteo nell'app Back-End.
- Un'API Web di back-end utilizza l'autenticazione JWT-bearer per convalidare i token JWT salvati dal sistema durante il processo di accesso.
- Aspire migliora l'esperienza di creazione di app native del cloud .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.
- L'app usa astrazioni sul lato server e sul lato client per visualizzare i dati meteo generati.
- Quando si esegue il rendering del componente
Weatherper visualizzare i dati meteo sul server, il componente utilizza ilServerWeatherForecaster. I pacchetti Web Microsoft Identity forniscono API per creare un servizio Web downstream denominato per effettuare chiamate API Web. IDownstreamApi viene inserito inServerWeatherForecaster, che viene usato per chiamare CallApiForUserAsync per ottenere dati meteo da un'API Web esterna (MinimalApiJwtprogetto). - Quando il componente
Weatherviene renderizzato sul client, utilizza l'implementazione del servizioClientWeatherForecaster, che utilizza un HttpClient preconfigurato (nel fileProgramdel progetto client) per effettuare una chiamata API Web all'API minima del progetto server (/weather-forecast) per ottenere i dati meteo. L'endpoint API minimo ottiene un token di accesso per l'utente chiamando GetAccessTokenForUserAsync. Oltre agli ambiti corretti, viene effettuata una chiamata di proxy inverso all'API Web esterna (MinimalApiJwtprogetto) per ottenere e restituire i dati meteo al client affinché il componente possa effettuare il rendering.
- Quando si esegue il rendering del componente
Prerequisites
Aspire richiede Visual Studio versione 17.10 o successiva.
Vedere anche la sezione Prerequisiti di Avvio rapido: Creare la prima Aspire soluzione.
Soluzione di esempio
La soluzione di esempio è costituita dai progetti seguenti:
-
Aspire:
-
Aspire.AppHost: usato per gestire le problematiche di orchestrazione generali dell'app. -
Aspire.ServiceDefaults: contiene configurazioni di app predefinite 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. -
BlazorWebAppEntra: progetto lato server di Blazor Web App. -
BlazorWebAppEntra.Client: Progetto client-side 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 BlazorWebAppEntraBff cartella per .NET 9 o versione successiva.
Visualizzare o scaricare il codice di esempio (procedura per il download)
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 BlazorWebAppEntra 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 (BlazorWebAppEntra) con una configurazione della piattaforma Web con due voci in URI di reindirizzamento: https://localhost/signin-oidc e https://localhost/signout-callback-oidc (le porte non sono necessarie in questi URI). L'ID tenant, il dominio 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 appsettings.json . 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.
Aspire progetti
Per ulteriori informazioni sull'utilizzo di Aspire e sui dettagli relativi ai progetti .AppHost e .ServiceDefaults dell'app di esempio, consultare la documentazione di Aspire.
Verificare di aver soddisfatto i prerequisiti per Aspire. Per altre informazioni, vedere la sezione Prerequisiti di Avvio rapido: Creare la prima Aspire soluzione.
L'app di esempio configura solo un profilo di avvio HTTP non sicuro (http) da usare durante i test di sviluppo. Per ulteriori informazioni, incluso un esempio di profili di impostazioni di avvio sicure e non sicure, vedere Consenti il trasporto non sicuro in Aspire (Aspire documentazione).
Progetto server Blazor Web App lato (BlazorWebAppEntra)
Il progetto BlazorWebAppEntra è il progetto lato server di Blazor Web App.
Progetto lato utente Blazor Web App (BlazorWebAppEntra.Client)
Il progetto BlazorWebAppEntra.Client rappresenta la parte lato client di Blazor Web App.
Se l'utente deve accedere o disconnettersi durante il rendering lato client, viene avviato un ricaricamento di pagina completo.
Progetto API Web per il back-end (MinimalApiJwt)
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 (BlazorWebAppEntra) vengono inviate tramite proxy al MinimalApiJwt progetto.
Il MinimalApiJwt.http file può essere usato per testare la richiesta di dati meteo. Si tenga presente che il progetto MinimalApiJwt deve essere in esecuzione per testare l'endpoint, e l'endpoint è incorporato nel codice del file. Per altre informazioni, vedere Usare file .http in Visual Studio 2022.
Il progetto include pacchetti e configurazione per produrre documenti OpenAPI.
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 API Web backend (MinimalApiJwt)
Configurare il MinimalApiJwt progetto nella classe JwtBearerOptions della AddJwtBearer chiamata nel file del Program progetto.
Per la registrazione dell'app per le API Web, l'ambito Weather.Get viene configurato nel portale entra o di Azure in Esporre un'API.
Authority imposta l'Autorità per effettuare chiamate OIDC.
jwtOptions.Authority = "{AUTHORITY}";
Gli esempi seguenti usano un ID tenant di aaaabbbb-0000-cccc-1111-dddd2222eeee e un nome directory di contoso.
Se l'app è registrata in un tenant ME-ID, l'autorità deve corrispondere all'issuer (iss) del token JWT restituito dal provider di identità.
jwtOptions.Authority = "https://sts.windows.net/aaaabbbb-0000-cccc-1111-dddd2222eeee";
Se l'app è registrata in un tenant di MICROSOFT Entra External ID:
jwtOptions.Authority = "https://contoso.ciamlogin.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0";
Se l'app è registrata in un tenant AAD B2C:
jwtOptions.Authority = "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0";
Note
Azure Active Directory B2C non è più disponibile come servizio ai nuovi clienti a partire dal 1° maggio 2025. I tenant di AAD B2C sono supportati per i clienti con account stabiliti prima del 1° maggio 2025 fino al 2030. Per altre informazioni, vedere Azure AD B2C: Domande frequenti.
Audience imposta il gruppo di destinatari per qualsiasi token di accesso JWT ricevuto.
jwtOptions.Audience = "{AUDIENCE}";
Trova solo il valore corrispondente al percorso dell'URI ID applicazione configurato quando aggiungi l'ambito sotto Weather.Get nel portale Entra o Azure. Non includere il nome dell'ambito "Weather.Get" nel valore.
Negli esempi seguenti viene usato un ID applicazione (client) di 11112222-bbbb-3333-cccc-4444dddd5555. Il terzo esempio usa un dominio tenant di contoso.onmicrosoft.com.
esempio di tenant ME-ID:
jwtOptions.Audience = "api://11112222-bbbb-3333-cccc-4444dddd5555";
Tenant del Microsoft Entra External ID
jwtOptions.Audience = "11112222-bbbb-3333-cccc-4444dddd5555";
Esempio di tenant per AAD B2C:
jwtOptions.Audience = "https://contoso.onmicrosoft.com/11112222-bbbb-3333-cccc-4444dddd5555";
Configurare il progetto server (BlazorWebAppEntra)
AddMicrosoftIdentityWebApp da Microsoft Identity Web (Microsoft.Identity.Web pacchetto NuGet, documentazione dell'API) è configurato nel BlazorWebAppEntra file del Program progetto.
Accedere all'ID applicazione (client), al dominio tenant (publisher) e all'ID directory (tenant) dalla registrazione dell'app nel portale Entra o di Azure. L'URI ID app viene ottenuto per l'ambito Weather.Get dalla registrazione dell'API Web. Non includere il nome dell'ambito quando si preleva l'URI ID app dal portale.
La configurazione di autenticazione dipende dal tipo di tenant:
configurazione del tenant ME-ID
Questa sezione si applica a un'app registrata in un tenant Microsoft Entra ID o Azure AAD B2C.
Nel file BlazorWebAppEntra del progetto Program, specificare i valori per i seguenti segnaposto nella configurazione Web di MicrosoftIdentity.
builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
.AddMicrosoftIdentityWebApp(msIdentityOptions =>
{
msIdentityOptions.CallbackPath = "/signin-oidc";
msIdentityOptions.ClientId = "{CLIENT ID (BLAZOR APP)}";
msIdentityOptions.Domain = "{DIRECTORY NAME}.onmicrosoft.com";
msIdentityOptions.Instance = "https://login.microsoftonline.com/";
msIdentityOptions.ResponseType = "code";
msIdentityOptions.TenantId = "{TENANT ID}";
})
.EnableTokenAcquisitionToCallDownstreamApi()
.AddDownstreamApi("DownstreamApi", configOptions =>
{
configOptions.BaseUrl = "{BASE ADDRESS}";
configOptions.Scopes = ["{APP ID URI}/Weather.Get"];
})
.AddDistributedTokenCaches();
Assicurarsi di fornire lo stesso scope dell'API downstream al trasformatore di richiesta.
List<string> scopes = ["{APP ID URI}/Weather.Get"];
Segnaposto nella configurazione precedente:
-
{CLIENT ID (BLAZOR APP)}: ID dell'applicazione (client). -
{DIRECTORY NAME}: nome della directory del dominio tenant (server di pubblicazione). -
{TENANT ID}: ID del tenant della directory. -
{BASE ADDRESS}: indirizzo di base dell'API Web. -
{APP ID URI}: URI dell'ID app per gli ambiti dell'API web. Viene usato uno dei formati seguenti, dove il segnaposto{CLIENT ID (WEB API)}è il Client Id della registrazione Entra dell'API Web e il segnaposto{DIRECTORY NAME}è il nome della directory del dominio del tenant (ad esempio:contoso).- ME-ID formato del tenant:
api://{CLIENT ID (WEB API)} - Formato tenant B2C:
https://{DIRECTORY NAME}.onmicrosoft.com/{CLIENT ID (WEB API)}
- ME-ID formato del tenant:
Example:
builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
.AddMicrosoftIdentityWebApp(msIdentityOptions =>
{
msIdentityOptions.CallbackPath = "/signin-oidc";
msIdentityOptions.ClientId = "00001111-aaaa-2222-bbbb-3333cccc4444";
msIdentityOptions.Domain = "contoso.onmicrosoft.com";
msIdentityOptions.Instance = "https://login.microsoftonline.com/";
msIdentityOptions.ResponseType = "code";
msIdentityOptions.TenantId = "aaaabbbb-0000-cccc-1111-dddd2222eeee";
})
.EnableTokenAcquisitionToCallDownstreamApi()
.AddDownstreamApi("DownstreamApi", configOptions =>
{
configOptions.BaseUrl = "https://localhost:7277";
configOptions.Scopes =
["api://11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get"];
})
.AddDistributedTokenCaches();
Example:
List<string> scopes = ["api://11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get"];
Configurazione di Microsoft Entra External ID
Questa sezione si applica a un'app registrata in un tenant di MICROSOFT Entra External ID.
Nel file BlazorWebAppEntra del progetto Program, specificare i valori per i seguenti segnaposto nella configurazione Web di MicrosoftIdentity.
builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
.AddMicrosoftIdentityWebApp(msIdentityOptions =>
{
msIdentityOptions.CallbackPath = "/signin-oidc";
msIdentityOptions.Authority = "https://{DIRECTORY NAME}.ciamlogin.com/{TENANT ID}/v2.0";
msIdentityOptions.ClientId = "{CLIENT ID (BLAZOR APP)}";
msIdentityOptions.ResponseType = "code";
})
.EnableTokenAcquisitionToCallDownstreamApi()
.AddDownstreamApi("DownstreamApi", configOptions =>
{
configOptions.BaseUrl = "{BASE ADDRESS}";
configOptions.Scopes = ["{APP ID URI}/Weather.Get"];
})
.AddDistributedTokenCaches();
Assicurarsi di fornire lo stesso scope dell'API downstream al trasformatore di richiesta.
List<string> scopes = ["{APP ID URI}/Weather.Get"];
Segnaposto nella configurazione precedente:
-
{DIRECTORY NAME}: nome della directory del dominio tenant (server di pubblicazione). -
{CLIENT ID (BLAZOR APP)}: ID dell'applicazione (client). -
{BASE ADDRESS}: indirizzo di base dell'API Web. -
{APP ID URI}: URI dell'ID app per gli ambiti dell'API web. Viene usato uno dei formati seguenti, dove il segnaposto{CLIENT ID (WEB API)}è il Client Id della registrazione Entra dell'API Web e il segnaposto{DIRECTORY NAME}è il nome della directory del dominio del tenant (ad esempio:contoso).- ME-ID o Microsoft Entra External ID in formato tenant:
api://{CLIENT ID (WEB API)} - Formato tenant B2C:
https://{DIRECTORY NAME}.onmicrosoft.com/{CLIENT ID (WEB API)}
- ME-ID o Microsoft Entra External ID in formato tenant:
Example:
builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
.AddMicrosoftIdentityWebApp(msIdentityOptions =>
{
msIdentityOptions.CallbackPath = "/signin-oidc";
msIdentityOptions.Authority = "https://contoso.ciamlogin.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0";
msIdentityOptions.ClientId = "00001111-aaaa-2222-bbbb-3333cccc4444";
msIdentityOptions.ResponseType = "code";
})
.EnableTokenAcquisitionToCallDownstreamApi()
.AddDownstreamApi("DownstreamApi", configOptions =>
{
configOptions.BaseUrl = "https://localhost:7277";
configOptions.Scopes = ["api://11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get"];
})
.AddDistributedTokenCaches();
Example:
List<string> scopes = ["api://11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get"];
Warning
Le app di produzione devono usare un provider di cache di token distribuito di produzione. In caso contrario, l'app potrebbe avere prestazioni scarse in alcuni scenari. Per altre informazioni, vedere la sezione Usare un provider di cache dei token distribuiti di produzione .
Il percorso di callback (CallbackPath) deve corrispondere all'URI di reindirizzamento (percorso di callback di accesso) configurato durante la registrazione dell'applicazione in Entra o portale di Azure. I percorsi vengono configurati nel pannello Autenticazione della registrazione dell'app. Il valore predefinito di CallbackPath è /signin-oidc per un URI di reindirizzamento registrato di https://localhost/signin-oidc (non è necessaria una porta).
SignedOutCallbackPath è il percorso della richiesta all'interno del percorso di base dell'app intercettato dal gestore OpenID Connect in cui l'agente utente viene restituito per la prima volta dopo la disconnessione da Entra. 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 OpenID Connect reindirizza al SignedOutRedirectUri o RedirectUri, se specificato.
Warning
Non archiviare segreti dell'app, stringa 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.
Stabilire il segreto del client
Questa sezione si applica solo al progetto server dell'oggetto Blazor Web App.
Usare uno o entrambi gli approcci seguenti per fornire il segreto client all'app:
- Strumento Secret Manager: lo strumento Secret Manager archivia i dati privati nel computer locale e viene usato solo durante lo sviluppo locale.
- Azure Key Vault: è possibile archiviare il segreto del client in un Key Vault da usare in qualsiasi ambiente, incluso l'ambiente di sviluppo quando si lavora in locale. Alcuni sviluppatori preferiscono utilizzare gli archivi chiave per le distribuzioni di staging e di produzione e lo strumento Secret Manager per lo sviluppo locale.
È consigliabile evitare di archiviare segreti client nel codice del progetto o nei file di configurazione. Usare flussi di autenticazione sicuri, ad esempio uno o entrambi gli approcci descritti in questa sezione.
Strumento Gestore Segreti
Lo strumento Secret Manager può archiviare il segreto del client dell'app server sotto la chiave di configurazione .
L'app Blazor server non è stata inizializzata 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, utilizzare il comando cd per spostarsi alla directory del progetto server. Il comando stabilisce un identificatore di segreti utente (<UserSecretsId>) nel file di progetto dell'app server, che viene usato internamente dagli strumenti per tenere traccia dei segreti per l'app:
dotnet user-secrets init
Eseguire il comando seguente per impostare il segreto client. Il {SECRET} segnaposto è il segreto client ottenuto dalla registrazione Entra dell'app:
dotnet user-secrets set "AzureAd: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.
Azure Key Vault (Archivio chiavi di Azure)
Azure Key Vault offre un approccio sicuro per fornire il segreto client dell'app all'app.
Per creare un Key Vault e impostare un segreto client, consulta Informazioni sui segreti di Azure Key Vault (documentazione di Azure), che collega le risorse per iniziare a usare Azure Key Vault. Per implementare il codice in questa sezione, registrare l'URI del Key Vault di Azure e il nome del segreto da Azure quando si crea il Key Vault e il segreto. Per l'esempio in questa sezione, il nome del segreto è "BlazorWebAppEntraClientSecret".
Quando si configura il vault delle chiavi nel portale Entra o Azure:
Configurare il Key Vault per utilizzare l'accesso basato sui ruoli di Azure. Se non si utilizza una rete virtuale di Azure, anche per sviluppo e test locali, assicurarsi che l'accesso pubblico nella sezione Rete sia abilitato (selezionato). L'abilitazione dell'accesso pubblico espone solo l'endpoint del Key Vault. Gli account autenticati sono ancora necessari per l'accesso.
Creare un'istanza gestita di Identity Azure (o aggiungere un ruolo all'istanza gestita Identity esistente che si prevede di usare) con il ruolo Utente segreti dell'insieme di credenziali delle chiavi . Assegna il Gestito Identity al servizio App di Azure che ospita la distribuzione: Impostazioni>Identity>Utente assegnato>Aggiungi.
Note
Se hai in programma di eseguire un'app in locale con un utente autorizzato per l'accesso al Key Vault usando l'interfaccia della riga di comando di Azure o l'autenticazione del servizio di Azure di Visual Studio, aggiungi il tuo account utente Azure di sviluppatore in Controllo di accesso (IAM) con il ruolo Utente segreti di Key Vault. Se si vuole usare l'interfaccia della riga di comando di Azure tramite Visual Studio, eseguire il
az logincomando dal pannello Developer PowerShell e seguire le istruzioni per l'autenticazione con il tenant.
Per implementare il codice in questa sezione, registrare l'URI del Key Vault (ad esempio: "https://contoso.vault.azure.net/", barra finale obbligatoria) e il nome del segreto (ad esempio: "BlazorWebAppEntraClientSecret") da Azure quando create il key vault e il segreto.
Important
Viene creato un segreto del vault delle chiavi con una data di scadenza. Assicurarsi di monitorare quando un segreto del key vault sta per scadere e creare un nuovo segreto per l'app prima che quella data venga superata.
Aggiungere la classe AzureHelper seguente al progetto server. Il metodo GetKeyVaultSecret recupera un segreto da un vault delle chiavi. Modificare lo spazio dei nomi (BlazorSample.Helpers) in modo che corrisponda allo schema dello spazio dei nomi del progetto.
Helpers/AzureHelper.cs:
using Azure.Core;
using Azure.Security.KeyVault.Secrets;
namespace BlazorWebAppEntra.Helpers;
public static class AzureHelper
{
public static string GetKeyVaultSecret(string vaultUri,
TokenCredential credential, string secretName)
{
var client = new SecretClient(new Uri(vaultUri), credential);
var secret = client.GetSecretAsync(secretName).Result;
return secret.Value.Value;
}
}
Note
L'esempio precedente usa DefaultAzureCredential per semplificare l'autenticazione durante lo sviluppo di app distribuite in Azure combinando le credenziali usate negli ambienti di hosting di Azure con le credenziali usate nello sviluppo locale. Quando si passa all'ambiente di produzione, un'alternativa è una scelta migliore, ad esempio ManagedIdentityCredential. Per altre informazioni, vedere Autenticare le app .NET ospitate in Azure nelle risorse di Azure usando un'identità gestita assegnata dal sistema.
Dove i servizi vengono registrati nel file del progetto server Program, acquisisci e applica il client secret usando il codice seguente:
TokenCredential? credential;
if (builder.Environment.IsProduction())
{
credential = new ManagedIdentityCredential("{MANAGED IDENTITY CLIENT ID}");
}
else
{
// Local development and testing only
DefaultAzureCredentialOptions options = new()
{
// Specify the tenant ID to use the dev credentials when running the app locally
// in Visual Studio.
VisualStudioTenantId = "{TENANT ID}",
SharedTokenCacheTenantId = "{TENANT ID}"
};
credential = new DefaultAzureCredential(options);
}
Dove MicrosoftIdentityOptions sono impostati, chiamare GetKeyVaultSecret per ricevere e assegnare il segreto client dell'app:
msIdentityOptions.ClientSecret = AzureHelper.GetKeyVaultSecret("{VAULT URI}",
credential, "{SECRET NAME}");
{MANAGED IDENTITY CLIENT ID}: ID client gestito di Identity Azure (GUID).
{TENANT ID}: ID del tenant della directory. Esempio: aaaabbbb-0000-cccc-1111-dddd2222eeee
{VAULT URI}: URI della cassaforte delle chiavi. Includere la barra finale sull'URL. Esempio: https://contoso.vault.azure.net/
{SECRET NAME}: nome del segreto. Esempio: BlazorWebAppEntraClientSecret
La configurazione viene utilizzata per facilitare la fornitura di archivi di chiavi dedicati e nomi segreti basati sui file di configurazione dell'ambiente dell'app. Ad esempio, è possibile specificare valori di configurazione diversi per appsettings.Development.json in fase di sviluppo, appsettings.Staging.json durante la gestione temporanea e appsettings.Production.json per la distribuzione di produzione. Per altre informazioni, vedere configurazione di ASP.NET CoreBlazor.
Serializzare solo il nome e le attestazioni del ruolo
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 di connessione Microsoft Web e JWT nei loro file Identity per rendere individuabili le impostazioni di configurazione utilizzando il completamento automatico 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 BlazorWebAppEntra progetto aggiungere la configurazione JSON seguente:
{
"AzureAd": {
"CallbackPath": "/signin-oidc",
"ClientId": "{CLIENT ID (BLAZOR APP)}",
"Domain": "{DIRECTORY NAME}.onmicrosoft.com",
"Instance": "https://login.microsoftonline.com/",
"ResponseType": "code",
"TenantId": "{TENANT ID}"
},
"DownstreamApi": {
"BaseUrl": "{BASE ADDRESS}",
"Scopes": ["{APP ID URI}/Weather.Get"]
}
}
Aggiornare i segnaposto nella configurazione precedente in modo che corrispondano ai valori usati dall'app nel Program file:
-
{CLIENT ID (BLAZOR APP)}: ID dell'applicazione (client). -
{DIRECTORY NAME}: nome della directory del dominio tenant (server di pubblicazione). -
{TENANT ID}: ID del tenant della directory. -
{BASE ADDRESS}: indirizzo di base dell'API Web. -
{APP ID URI}: URI dell'ID app per gli ambiti dell'API web. Viene usato uno dei formati seguenti, dove il segnaposto{CLIENT ID (WEB API)}è il Client Id della registrazione Entra dell'API Web e il segnaposto{DIRECTORY NAME}è il nome della directory del dominio del tenant (ad esempio:contoso).- ME-ID formato del tenant:
api://{CLIENT ID (WEB API)} - Formato tenant B2C:
https://{DIRECTORY NAME}.onmicrosoft.com/{CLIENT ID (WEB API)}
- ME-ID formato del tenant:
Example:
"AzureAd": {
"CallbackPath": "/signin-oidc",
"ClientId": "00001111-aaaa-2222-bbbb-3333cccc4444",
"Domain": "contoso.onmicrosoft.com",
"Instance": "https://login.microsoftonline.com/",
"ResponseType": "code",
"TenantId": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
},
"DownstreamApi": {
"BaseUrl": "https://localhost:7277",
"Scopes": ["api://11112222-bbbb-3333-cccc-4444dddd5555/Weather.Get"]
}
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.
Apportare le modifiche seguenti nel Program file:
builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
- .AddMicrosoftIdentityWebApp(msIdentityOptions =>
- {
- msIdentityOptions.CallbackPath = "...";
- msIdentityOptions.ClientId = "...";
- msIdentityOptions.Domain = "...";
- msIdentityOptions.Instance = "...";
- msIdentityOptions.ResponseType = "...";
- msIdentityOptions.TenantId = "...";
- })
+ .AddMicrosoftIdentityWebApp(builder.Configuration.GetSection("AzureAd"))
.EnableTokenAcquisitionToCallDownstreamApi()
- .AddDownstreamApi("DownstreamApi", configOptions =>
- {
- configOptions.BaseUrl = "...";
- configOptions.Scopes = ["..."];
- })
+ .AddDownstreamApi("DownstreamApi", builder.Configuration.GetSection("DownstreamApi"))
.AddDistributedTokenCaches();
- List<string> scopes = ["{APP ID URI}/Weather.Get"];
- var accessToken = await tokenAcquisition.GetAccessTokenForUserAsync(scopes);
+ var configuration = transformContext.HttpContext.RequestServices.GetRequiredService<IConfiguration>();
+ var scopes = configuration.GetSection("DownstreamApi:Scopes").Get<IEnumerable<string>>();
+ var accessToken = await tokenAcquisition.GetAccessTokenForUserAsync(scopes ??
+ throw new InvalidOperationException("No downstream API scopes!"));
Note
Le app di produzione devono usare un provider di cache di token distribuito di produzione. In caso contrario, l'app potrebbe avere prestazioni scarse in alcuni scenari. Per altre informazioni, vedere la sezione Usare un provider di cache dei token distribuiti di produzione .
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 locatario:
https://sts.windows.net/{TENANT ID} - Microsoft Entra External ID (ID esterno Microsoft Entra):
https://{DIRECTORY NAME}.ciamlogin.com/{TENANT ID}/v2.0 - 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 locatario:
api://{CLIENT ID} - Microsoft Entra External ID (ID esterno Microsoft Entra):
{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 un provider di cache dei token distribuiti di produzione
Le cache dei token distribuiti in memoria vengono create quando si chiama AddDistributedTokenCaches per assicurarsi che sia disponibile un'implementazione di base per la memorizzazione nella cache dei token distribuiti.
Le app Web di produzione e le API Web devono usare una cache dei token distribuiti di produzione, ad esempio Redis, Microsoft SQL Server, Microsoft Azure Cosmos DB.
Note
Per lo sviluppo locale e il test in un singolo computer, è possibile usare le cache dei token in memoria anziché le cache dei token distribuiti:
builder.Services.AddInMemoryTokenCaches();
Più avanti nel periodo di sviluppo e test, adottare un provider di cache distribuita di token in produzione.
AddDistributedMemoryCache aggiunge un'implementazione predefinita di che archivia gli elementi della IDistributedCache cache in memoria, che viene usata da Microsoft Identity Web per la memorizzazione nella cache dei token.
La cache dei token distribuiti è configurata da MsalDistributedTokenCacheAdapterOptions:
- In fase di sviluppo a scopo di debug, è possibile disabilitare la cache L1 impostando DisableL1Cache su
true. Assicurati di ripristinarlo al valorefalseper l'ambiente di produzione. - Imposta la dimensione massima della cache L1 con
L1CacheOptions.SizeLimitper evitare che la cache sovraccarichi la memoria del server. Il valore predefinito è 500 MB. - In fase di sviluppo a scopo di debug, è possibile disabilitare la crittografia dei token inattivi impostando Encrypt su
false, ovvero il valore predefinito. Assicurati di ripristinarlo al valoretrueper l'ambiente di produzione. - Impostare la rimozione del token dalla cache con SlidingExpiration. Il valore predefinito è 1 ora.
- Per altre informazioni, incluse le indicazioni sul callback per gli errori della cache L2 (OnL2CacheFailure) e le scritture asincrone di cache L2 (EnableAsyncL2Write), vedere MsalDistributedTokenCacheAdapterOptions e Serializzazione della cache dei token: cache dei token distribuiti.
builder.Services.AddDistributedMemoryCache();
builder.Services.Configure<MsalDistributedTokenCacheAdapterOptions>(
options =>
{
// The following lines that are commented out reflect
// default values. We recommend overriding the default
// value of Encrypt to encrypt tokens at rest.
//options.DisableL1Cache = false;
//options.L1CacheOptions.SizeLimit = 500 * 1024 * 1024;
options.Encrypt = true;
//options.SlidingExpiration = TimeSpan.FromHours(1);
});
AddDistributedMemoryCache richiede un riferimento al Microsoft.Extensions.Caching.Memory pacchetto NuGet.
Note
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.
Per configurare un provider di cache distribuita di produzione, vedere Memorizzazione nella cache distribuita in ASP.NET Core.
Warning
Sostituire sempre le cache dei token distribuiti in memoria con un provider di cache dei token reale durante la distribuzione dell'app in un ambiente di produzione. Se non si adotta un provider di cache dei token distribuiti in produzione, l'app potrebbe subire un calo significativo delle prestazioni.
Per altre informazioni, vedere Serializzazione della cache dei token: Cache distribuita. Tuttavia, gli esempi di codice illustrati non si applicano alle app ASP.NET Core, che configurano le cache distribuite tramite AddDistributedMemoryCache, non AddDistributedTokenCache.
Usare un portachiavi di protezione dei dati condiviso nell'ambiente di produzione in modo che le istanze dell'app su server in una web farm possano decrittografare i token quando MsalDistributedTokenCacheAdapterOptions.Encrypt è impostato su true.
Note
Per lo sviluppo anticipato e i test locali in un singolo computer, è possibile impostare Encryptfalse su e configurare un anello di chiave di protezione dati condiviso in un secondo momento:
options.Encrypt = false;
Più avanti nel periodo di sviluppo e test abilitare la crittografia dei token e adottare un anello di chiave di protezione dei dati condiviso.
L'esempio seguente illustra come usare Azure Blob Storage e Azure Key Vault (PersistKeysToAzureBlobStorage/ProtectKeysWithAzureKeyVault) per l'anello di chiavi condiviso. Le configurazioni del servizio sono scenari caso di base a scopo dimostrativo. Prima di distribuire le app di produzione, acquisire familiarità con i servizi di Azure e adottare le procedure consigliate usando i set di documentazione dedicati dei servizi di Azure, collegati alla fine di questa sezione.
Verificare la presenza dei pacchetti seguenti nel progetto server di Blazor Web App:
Note
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.
Note
Prima di procedere con i passaggi seguenti, verificare che l'app sia registrata con Microsoft Entra.
Il codice seguente viene in genere implementato contemporaneamente all'implementazione di un provider di cache di token distribuito di produzione . Altre opzioni, sia all'interno di Azure che all'esterno di Azure, sono disponibili per la gestione delle chiavi di protezione dei dati in più istanze dell'app, ma l'app di esempio illustra come usare i servizi di Azure.
Configurare Archiviazione BLOB di Azure per gestire le chiavi di protezione dei dati. Segui le indicazioni fornite in Provider di archiviazione chiavi in ASP.NET Core.
Configurare Azure Key Vault per crittografare le chiavi di protezione dei dati a riposo. Seguire le indicazioni in Configurare ASP.NET Protezione dati di base.
Usare il codice seguente nel file in Program cui vengono registrati i servizi:
TokenCredential? credential;
if (builder.Environment.IsProduction())
{
credential = new ManagedIdentityCredential("{MANAGED IDENTITY CLIENT ID}");
}
else
{
// Local development and testing only
DefaultAzureCredentialOptions options = new()
{
// Specify the tenant ID to use the dev credentials when running the app locally
// in Visual Studio.
VisualStudioTenantId = "{TENANT ID}",
SharedTokenCacheTenantId = "{TENANT ID}"
};
credential = new DefaultAzureCredential(options);
}
builder.Services.AddDataProtection()
.SetApplicationName("BlazorWebAppEntra")
.PersistKeysToAzureBlobStorage(new Uri("{BLOB URI}"), credential)
.ProtectKeysWithAzureKeyVault(new Uri("{KEY IDENTIFIER}"), credential);
È possibile passare qualsiasi nome dell'app a SetApplicationName. È sufficiente verificare che tutte le distribuzioni di app usino lo stesso valore.
{MANAGED IDENTITY CLIENT ID}: ID client gestito di Identity Azure (GUID).
{TENANT ID}: ID del tenant.
{BLOB URI}: URI completo del file di chiave. L'URI viene generato da Azure Storage quando viene creato il file della chiave. Non usare un SAS.
{KEY IDENTIFIER}: identificatore di chiave di Azure Key Vault usato per la crittografia delle chiavi. Un criterio di accesso consente all'applicazione di accedere al key vault con le autorizzazioni Get, Unwrap Key e Wrap Key. La versione della chiave viene ottenuta dalla chiave nel portale Entra o nel portale Azure dopo che è stata creata. Se si abilita l'autorotazione della chiave del Key Vault, assicurarsi di utilizzare un identificatore di chiave senza versione nella configurazione del Key Vault dell'app, dove non viene inserito alcun GUID della chiave alla fine dell'identificatore (ad esempio: https://contoso.vault.azure.net/keys/data-protection).
Note
Negli ambienti non di produzione, l'esempio precedente usa DefaultAzureCredential per semplificare l'autenticazione durante lo sviluppo di app distribuite in Azure combinando le credenziali usate negli ambienti di hosting di Azure con le credenziali usate nello sviluppo locale. Per altre informazioni, vedere Autenticare le app .NET ospitate in Azure nelle risorse di Azure usando un'identità gestita assegnata dal sistema.
In alternativa, è possibile configurare l'app per fornire i valori dai file di impostazioni dell'app usando il provider di configurazione JSON. Aggiungere quanto segue al file delle impostazioni dell'app:
"DistributedTokenCache": {
"DisableL1Cache": false,
"L1CacheSizeLimit": 524288000,
"Encrypt": true,
"SlidingExpirationInHours": 1
},
"DataProtection": {
"BlobUri": "{BLOB URI}",
"KeyIdentifier": "{KEY IDENTIFIER}"
}
Sezione di esempio DataProtection :
"DataProtection": {
"BlobUri": "https://contoso.blob.core.windows.net/data-protection/keys.xml",
"KeyIdentifier": "https://contoso.vault.azure.net/keys/data-protection"
}
Note
L'identificatore di chiave nell'esempio precedente è senza versione. Non esiste alcuna versione della chiave GUID alla fine dell'identificatore. Ciò è particolarmente importante se si sceglie di configurare la rotazione automatica delle chiavi per la chiave. Per altre informazioni, vedere Configurare la rotazione automatica delle chiavi crittografiche in Azure Key Vault: Criteri di rotazione delle chiavi.
Apportare le modifiche seguenti nel Program file:
builder.Services.Configure<MsalDistributedTokenCacheAdapterOptions>(
options =>
{
+ var config = builder.Configuration.GetSection("DistributedTokenCache");
- options.DisableL1Cache = false;
+ options.DisableL1Cache = config.GetValue<bool>("DisableL1Cache");
- options.L1CacheOptions.SizeLimit = 500 * 1024 * 1024;
+ options.L1CacheOptions.SizeLimit = config.GetValue<long>("L1CacheSizeLimit");
- options.Encrypt = true;
+ options.Encrypt = config.GetValue<bool>("Encrypt");
- options.SlidingExpiration = TimeSpan.FromHours(1);
+ options.SlidingExpiration =
+ TimeSpan.FromHours(config.GetValue<int>("SlidingExpirationInHours"));
});
- builder.Services.AddDataProtection()
- .SetApplicationName("BlazorWebAppEntra")
- .PersistKeysToAzureBlobStorage(new Uri("{BLOB URI}"), credential)
- .ProtectKeysWithAzureKeyVault(new Uri("{KEY IDENTIFIER}"), credential);
Aggiungere il codice seguente in cui i servizi sono configurati nel Program file:
var config = builder.Configuration.GetSection("DataProtection");
builder.Services.AddDataProtection()
.SetApplicationName("BlazorWebAppEntra")
.PersistKeysToAzureBlobStorage(
new Uri(config.GetValue<string>("BlobUri") ??
throw new Exception("Missing Blob URI")),
credential)
.ProtectKeysWithAzureKeyVault(
new Uri(config.GetValue<string>("KeyIdentifier") ??
throw new Exception("Missing Key Identifier")),
credential);
Per altre informazioni sull'uso di un anello di chiave di protezione dei dati condiviso e di provider di archiviazione delle chiavi, vedere le risorse seguenti:
- Provider di archiviazione chiavi in ASP.NET Core
- Configurare ASP.NET protezione dei dati di base
- Usare Azure SDK per .NET nelle app ASP.NET Core
- Ospitare ASP.NET Core in una Web farm: Protezione dei dati
- Configurare ASP.NET protezione dei dati di base
- Provider di archiviazione chiavi in ASP.NET Core
- documentazione di Azure Key Vault
- documentazione di Archiviazione di Azure
- Fornire l'accesso a chiavi, certificati e segreti di Key Vault con il controllo degli accessi in base al ruolo di Azure
Prefisso di destinazione del server d'inoltro YARP
Il forwarder YARP del progetto Blazor Web App server, dove il token di accesso dell'utente è allegato alla chiamata API web MinimalApiJwt, specifica un prefisso di destinazione di https://weatherapi. Questo valore corrisponde al nome del progetto passato al AddProjectProgram file del Aspire.AppHost progetto.
Inoltro nel progetto del server Blazor Web App (BlazorWebAppEntra):
app.MapForwarder("/weather-forecast", "https://weatherapi", transformBuilder =>
{
...
}).RequireAuthorization();
Nome del progetto corrispondente nel Program file del Aspire progetto Host app (Aspire.AppHost):
var weatherApi = builder.AddProject<Projects.MinimalApiJwt>("weatherapi");
Non è necessario modificare il prefisso di destinazione del server d'inoltro YARP durante la distribuzione di Blazor Web App in produzione. Il pacchetto Microsoft Identity Web Downstream API utilizza l'URI di base passato tramite configurazione per effettuare la chiamata API Web da ServerWeatherForecaster, non dal prefisso di destinazione del server d'inoltro YARP. Nell'ambiente di produzione, il server d'inoltro YARP trasforma semplicemente la richiesta, aggiungendo il token di accesso dell'utente.
Reindirizzare alla pagina iniziale dopo la 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, utilizzare il componente LogInOrOut seguente, 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>
Sicurezza dei dati meteo
Per ulteriori informazioni su come questa app assicura i dati meteorologici, vedere Protezione dei dati in Blazor Web Appcon rendering automatico interattivo.
Troubleshoot
Logging
L'app server è un'app standard ASP.NET Core. Consultare le linee guida di logging di ASP.NET Core per abilitare un livello di log più basso nell'app server.
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 arresta il debugger di Visual Studio durante la disconnessione da 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 dell'IP. Si noti che non è richiesta la configurazione di una porta per Microsoft Entra ID e un'app in esecuzione a un indirizzo di test di sviluppo
localhost, ma la configurazione della porta dell'app e la porta su cui l'app è in esecuzione devono corrispondere per gli indirizzi nonlocalhost.
La copertura di 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 è disponibile nei seguenti articoli:
- 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 del framework non sensibili e non riservati, segnalare un problema all'unità prodotto di 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:
- Nella portale di Azure accedere al manifesto dell'app.
- Impostare l'attributo
allowPublicClientsunullo .true
- Errore:
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
- Utilizzare un browser configurabile per i test in grado di eliminare 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:
- Apri la finestra di dialogo Sfoglia con dal pulsante Esegui di Visual Studio.
- Seleziona 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
- Microsoft Edge:
-
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).
- Microsoft Edge: usare
- Fornire un nome nel campo Nome descrittivo. 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 delle app
Un'app funzionante potrebbe bloccarsi immediatamente dopo l'aggiornamento dell'SDK di .NET nel computer 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 --clearda una shell dei comandi. - Eliminare le cartelle
bineobjdel progetto. - Ripristina e ricostruisci il progetto.
- Eliminare tutti i file nella cartella di distribuzione nel server prima di ridistribuire l'app.
Note
L'uso di versioni del pacchetto incompatibili con il framework di destinazione dell'app non è supportato. Per informazioni su un pacchetto, utilizzare la NuGet Gallery.
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
- Chiamare un'API Web da un'app ASP.NET Core Blazor : Microsoft Identity Platform per le chiamate API Web
- documentazione di Microsoft Identity Platform
- Documentazione dell'API Web | Microsoft Identity Platform
- API Web che chiama LE API Web: Chiamare un'API: Opzione 2: Chiamare un'API Web downstream con la classe helper
-
AzureAD/microsoft-identity-webRepository GitHub: indicazioni utili sull'implementazione di Microsoft Web per Microsoft Identity 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, la documentazione di Azure non affronta esplicitamente il caso di Blazor Web App, ma l'installazione e la configurazione di un Blazor Web App per l'ID ME e l'hosting su Azure sono analoghe a quelle di qualsiasi applicazione web ASP.NET Core. -
AuthenticationStateProviderservizio - Gestire lo stato di autenticazione in Blazor Web Apps
- Astrazioni di servizio in Blazor Web Apps