Considerazioni sulla disponibilità elevata in MSAL.NET

Per il flusso delle credenziali client, vedere prima la documentazione relativa ai flussi di credenziali client .

Usare un'API di livello superiore

MSAL è un'API di livello inferiore. Se stai scrivendo una nuova app, prendi in considerazione l'uso del livello Microsoft.Identitity.Web superiore che fornisce l'integrazione predefinita con ASP.NET Core e ASP.NET classico.

Usare la versione più recente di MSAL

Usare la versione più recente di MSAL per ottenere le correzioni di bug e i miglioramenti delle prestazioni. Vengono seguite le regole di controllo delle versioni semantiche.

Si vuole anche verificare se è consigliabile usare Microsoft Identity Web, una libreria di livello superiore per le app Web e le API Web, che esegue molte delle operazioni descritte di seguito per l'utente. Vedere Scelta di una versione di MSAL.NET, che propone un albero delle decisioni per scegliere la soluzione migliore a seconda della piattaforma e dei vincoli.

Usare la cache dei token

Comportamento predefinito: MSAL memorizza nella cache i token in memoria. Ogni ConfidentialClientApplication istanza ha una propria cache di token interna. La cache in memoria può essere persa, ad esempio se l'istanza dell'oggetto viene eliminata o l'intera applicazione viene arrestata.

Raccomandazione: Tutte le app devono rendere persistenti le cache dei token. Le app Web e le API Web devono usare una cache dei token L1/L2 in cui L2 è un archivio distribuito come Redis per gestire la scalabilità. Le app desktop devono usare una strategia di serializzazione della cache dei token appropriata.

Comportamento predefinito: MSAL gestisce una cache di token ADAL secondaria per scenari di migrazione tra ADAL e MSAL. Le operazioni della cache ADAL sono molto lente. Raccomandazione: Disabilitare la cache ADAL se non si è interessati alla migrazione da ADAL. In questo modo verrà apportato un miglioramento delle prestazioni BIG . Vedere le misurazioni delle prestazioni qui.

Aggiungi WithLegacyCacheCompatibility(false) durante la costruzione dell'app per disabilitare la memorizzazione nella cache di ADAL.

Aggiungere il monitoraggio per le operazioni MSAL

MSAL espone metriche importanti come parte dell'oggetto AuthenticationResult.AuthenticationResultMetadata :

Logging

Ascoltare i messaggi di livello Warning e Error provenienti dai log di MSAL. Questi possono essere errori invisibile all'utente o raccomandazioni complesse per l'uso di una configurazione diversa. Non è consigliabile impostare Verbose la registrazione nell'ambiente di produzione, perché produce molti messaggi e influisce sulle prestazioni.

Per informazioni dettagliate sulla registrazione, vedere la Guida alla registrazione in MSAL.NET.

Criteri di ripetizione

Comportamento predefinito: MSAL ritenta le richieste 5xx non riuscite una sola volta.

Raccomandazione:

• Vedere la nostra documentazione sui criteri di ripetizione dei tentativi per informazioni su come scrivere un criterio di ripetizione dei tentativi con Polly

Un client riservato per sessione

È consigliabile usare un nuovo ConfidentialClientApplication in ogni sessione e serializzare nello stesso modo, ovvero una cache di token per sessione. Questa scalabilità è ottimale e aumenta anche la sicurezza. Gli esempi ufficiali illustrano come eseguire questa operazione. Per il corretto funzionamento della memorizzazione nella cache dei token, è necessario configurare la memorizzazione nella cache dei token .

HttpClient

Comportamento predefinito: l'oggetto HttpClient creato da MSAL non scala bene per siti Web/API Web, per i quali è consigliabile avere un oggetto ClientApplication per ogni sessione utente.

Raccomandazione: fornire una propria HttpClientFactory scalabile. In .NET Core si consiglia di iniettare System.Net.Http.IHttpClientFactory. Questo è descritto più dettagliatamente nella guida Fornire il proprio HttpClient, supporto per proxy HTTP e personalizzazione delle intestazioni User-Agent e nella documentazione di .NET

Rinnovo proattivo dei token

Obiettivo

Aumentare la disponibilità dell'applicazione rilasciando token di accesso di lunga durata e assicurarsi che vengano aggiornati prima della data di scadenza.

Status quo

Per impostazione predefinita, Microsoft Entra ID rilascia i token di accesso con scadenza di 1 ora. Se si verifica un'interruzione Microsoft Entra quando è necessario aggiornare un token, MSAL avrà esito negativo. L'errore si propaga all'applicazione chiamante e influisce sulla disponibilità.

Processo

Per migliorare la disponibilità MSAL tenta di assicurarsi che un'app disponga sempre di token non scaduti aggiornati. Microsoft Entra interruzioni richiedono raramente più di alcune ore, quindi se MSAL può garantire che un token abbia sempre almeno alcune ore di disponibilità lasciate, l'applicazione non sarà interessata dall'interruzione del Microsoft Entra.

Per ottenere token di lunga durata, è necessario configurare il tenant (nota: i tenant interni Microsoft sono già configurati). Per client_credentials (servizio 2), questo è sufficiente. Per le credenziali degli utenti, è necessario configurare anche CAE - /azure/active-directory/conditional-access/concept-continuous-access-evaluation.

Quando Microsoft Entra ID restituisce un token di lunga durata, include un campo refresh_in. In genere è impostato su metà della scadenza del token di accesso.

Nota: da MSAL 4.37.0 e successive, è possibile osservare questo valore esaminando AuthenticationResult.AuthenticationResultMetadata.RefreshOn.

È anche possibile configurare una durata del token superiore a 1 ora predefinita, come descritto in Durata dei token configurabili nella Microsoft Identity Platform (anteprima).

Ogni volta che si effettuano richieste per lo stesso token, ad esempio ogni volta che MSAL è in grado di servire un token dalla cache, MSAL verificherà automaticamente il refresh_in valore. Se è scaduto, MSAL invierà in background una richiesta di token a Microsoft Entra ID, ma restituirà all'applicazione il token esistente, ancora valido. Nel caso improbabile che l'aggiornamento in background non vada a buon fine (ad esempio, un'interruzione di Microsoft Entra), l'app non ne risente.

Rotazione dei certificati

I certificati per l'app client riservata devono essere ruotati per motivi di sicurezza (non usare segreti in prod!). Esistono diversi modi per gestire la rotazione dei certificati, in ordine di preferenza, dal più consigliato al meno consigliato:

1. Usare l'identità gestita

Con l'identità gestita, l'attendibilità viene stabilita tramite l'hosting dell'app in Azure. Non ci sono segreti da gestire né certificati da rinnovare.

2. Usare la logica di gestione dei Microsoft.Identity.Web certificati

Nelle app Web e nelle API Web usare Microsoft.Identity.Web, un'API di livello superiore su MSAL. Gestisce la rotazione dei certificati quando il certificato viene archiviato in Azure Key Vault e gestisce anche il caso di identità gestita.

Altre informazioni nella guida Certificates in Microsoft.Identity.Web.

Si tratta della soluzione preferita per i servizi interni non Microsoft usando ASP.NET Core.

3. (Solo per uso interno Microsoft) Usare i certificati Nome soggetto/Autorità emittente.

Questo meccanismo consente a Microsoft Entra ID di identificare un certificato in base a SN/I anziché a un'impronta digitale (x5t). Si tratta di una soluzione di stop-gap; non sono previsti piani per renderlo disponibile per le applicazioni non Microsoft.

Si tratta della soluzione preferita per Microsoft servizi interni che non sono in grado di usare l'identità gestita.