Aumentare la resilienza di autenticazione e autorizzazione nelle applicazioni client in corso di sviluppo

Articolo
10/24/2023

Informazioni su come creare resilienza nelle applicazioni client che usano Microsoft Identity Platform e Microsoft Entra ID per consentire l'accesso degli utenti ed eseguire azioni per conto di tali utenti.

Usare Microsoft Authentication Library (MSAL)

Microsoft Authentication Library (MSAL) fa parte di Microsoft Identity Platform. MSAL acquisisce, gestisce, memorizza nella cache e aggiorna i token; usa le procedure consigliate per la resilienza. MSAL consente agli sviluppatori di creare soluzioni sicure.

Altre informazioni:

MSAL memorizza nella cache i token e usa un modello di acquisizione di token invisibile all'utente. MSAL serializza la cache dei token nei sistemi operativi che forniscono in modo nativo l'archiviazione sicura, come ad esempio Universal Windows Platform (UWP), iOS e Android. Personalizzare il comportamento di serializzazione quando si usa:

Microsoft.Identity.Web
MSAL.NET
MSAL per Java
MSAL per Python

Altre informazioni:

Quando si usa MSAL, la memorizzazione nella cache dei token, l'aggiornamento e l'acquisizione invisibile all'utente sono supportate. Usare modelli semplici per acquisire i token per l'autenticazione. È disponibile il supporto per molte lingue. Trovare l'esempio di codice in Esempi di codice per Microsoft Identity Platform.

C#
JavaScript

try
{
    result = await app.AcquireTokenSilent(scopes, account).ExecuteAsync();
}
catch(MsalUiRequiredException ex)
{
    result = await app.AcquireToken(scopes).WithClaims(ex.Claims).ExecuteAsync()
}

return myMSALObj.acquireTokenSilent(request).catch(error => {
    console.warn("silent token acquisition fails. acquiring token using redirect");
    if (error instanceof msal.InteractionRequiredAuthError) {
        // fallback to interaction when silent call fails
        return myMSALObj.acquireTokenPopup(request).then(tokenResponse => {
            console.log(tokenResponse);

            return tokenResponse;
        }).catch(error => {
            console.error(error);
        });
    } else {
        console.warn(error);
    }
});

MSAL è in grado di aggiornare i token. Quando Microsoft Identity Platform rilascia un token di lunga durata, può inviare informazioni al client per aggiornare il token (refresh_in). L'app viene eseguita mentre il token precedente è valido, ma richiede più tempo per un'altra acquisizione di token.

Versioni di MSAL

È consigliabile che gli sviluppatori creino un processo per usare la versione MSAL più recente perché l'autenticazione rientra nella sicurezza delle app. Usare questa procedura per le librerie in fase di sviluppo e migliorare la resilienza delle app.

Trovare la versione più recente e note sulla versione:

Modelli resilienti per la gestione dei token

Se non si usa MSAL, usare modelli resilienti per la gestione dei token. La libreria MSAL implementa le procedure consigliate.

In genere, le applicazioni che usano l'autenticazione moderna chiamano un endpoint per recuperare i token che autenticano l'utente o autorizzare l'applicazione a chiamare le API protette. MSAL gestisce l'autenticazione e implementa modelli per migliorare la resilienza. Se non si usa MSAL, usare le indicazioni riportate in questa sezione per le procedure consigliate. In caso contrario, MSAL implementa automaticamente le procedure consigliate.

Token della cache

Accertarsi che le app memorizzano nella cache i token in modo accurato da Microsoft Identity Platform. Dopo che l'app riceve i token, la risposta HTTP con token ha una proprietà expires_in che indica la durata della memorizzazione nella cache e quando riutilizzarla. Verificare che l'applicazione non tenti di decodificare un token di accesso all'API.

Diagramma di un'app che chiama Microsoft Identity Platform tramite una cache di token nel dispositivo che esegue l'applicazione.

I token memorizzati nella cache impediscono il traffico non necessario tra un'app e Microsoft Identity Platform. Questo scenario rende l'app meno vulnerabile agli errori di acquisizione dei token riducendo le chiamate di acquisizione dei token. I token memorizzati nella cache migliorano le prestazioni dell'applicazione in quanto l'app blocca l'acquisizione di token meno frequentemente. Gli utenti rimangono connessi all'applicazione per la durata del token.

Serializzare e rendere persistenti i token

Accertarsi che le app serializzino la cache dei token in modo sicuro per rendere persistenti i token tra le istanze dell'app. Riutilizzare i token durante la loro durata. I token di aggiornamento e i token di accesso vengono emessi per molte ore. Durante questo lasso di tempo, gli utenti potrebbero avviare l'applicazione più volte. All'avvio di un'app, verificare che cerchi l'accesso valido o un token di aggiornamento. In questo modo si aumentano la resilienza e le prestazioni dell'app.

Altre informazioni:

Verificare che l'archiviazione token persistente disponga del controllo di accesso e della crittografia, in relazione all'identità dell'utente o del processo. In vari sistemi operativi sono disponibili funzionalità di archiviazione delle credenziali.

Acquisire i token in modo invisibile all'utente

L'autenticazione di un utente o il recupero dell'autorizzazione per chiamare un'API comporta più passaggi in Microsoft Identity Platform. Ad esempio, gli utenti che accedono per la prima volta immettono le credenziali ed eseguono un'autenticazione a più fattori. Ogni passaggio influisce sulla risorsa che fornisce il servizio. La migliore esperienza utente con meno dipendenze è l'acquisizione di token invisibile all'utente.

Diagramma dei servizi di Microsoft Identity Platform che consentono di completare l'autenticazione utente o l'autorizzazione.

L'acquisizione di token invisibile all'utente inizia con un token valido dalla cache dei token dell'app. Se non è disponibile nessun token valido, l'app tenta di acquisire un token usando un token di aggiornamento disponibile e l'endpoint del token. Se nessuna delle opzioni è disponibile, l'app acquisisce un token usando il parametro prompt=none. Questa azione usa l'endpoint di autorizzazione, ma l’utente non visualizza nessuna interfaccia utente. Se possibile, Microsoft Identity Platform fornisce un token all'app senza interazione dell'utente. Se nessun metodo restituisce un token, l'utente esegue manualmente l'autenticazione.

Nota

In generale, accertarsi che le app non usino comandi come “login” e “consent”. Questi prompt forzano l'interazione dell'utente pur non essendo necessaria nessuna interazione.

Gestione del codice di risposta

Usare le sezioni seguenti per informazioni sui codici di risposta.

Codice di risposta HTTP 429

Esistono risposte di errore che influiscono sulla resilienza. Se l'applicazione riceve un codice di risposta HTTP 429, Troppe richieste, Microsoft Identity Platform limita le richieste. Se un'app effettua troppe richieste, viene limitata affinché non riceva token. Non consentire a un'app di tentare l'acquisizione del token prima del completamento del campo di risposta Retry-After. Spesso, una risposta 429 indica che l'applicazione non memorizza nella cache e riutilizza correttamente i token. Verificare come i token vengono memorizzati nella cache e riutilizzati nell'applicazione.

Codice di risposta HTTP 5x

Se un'applicazione riceve un codice di risposta HTTP 5x, l'app non deve immettere un ciclo di ripetizione rapido. Gestire allo stesso modo una risposta 429. Se non compare nessuna intestazione Retry-After, implementare un nuovo tentativo di back-off esponenziale con il primo tentativo, almeno 5 secondi dopo la risposta.

Quando si verifica il timeout di una richiesta, sono sconsigliati tentativi immediati. Implementare tentativi di back-off esponenziali, con il primo tentativo almeno 5 secondi dopo la risposta.

Molte applicazioni e API necessitano di informazioni utente per autorizzare. I metodi disponibili presentano vantaggi e svantaggi.

OAuth

I token di identità (ID) e i token di accesso hanno attestazioni standard che forniscono informazioni. Se le informazioni necessarie si trovano nel token, la tecnica più efficiente è attestazioni token, perché impedisce un'altra chiamata di rete. Meno chiamate di rete equivalgono a una migliore resilienza.

Altre informazioni:

Nota

Alcune applicazioni chiamano l'endpoint UserInfo per recuperare le attestazioni relative all'utente autenticato. Le informazioni nel token ID sono un superset di informazioni dall'endpoint UserInfo. Abilitare le app per usare il token ID anziché chiamare l'endpoint UserInfo.

Aumentare le attestazioni di token standard con attestazioni facoltative, come ad esempio i gruppi. L'opzione Gruppo di applicazioni include i gruppi assegnati all'applicazione. Le opzioni Tutti o Gruppi di sicurezza includono gruppi di app nello stesso tenant, in grado di aggiungere gruppi al token. Valutare l'effetto, perché può negare l'efficienza della richiesta di gruppi nel token causando il bloat del token e richiedendo più chiamate per ottenere i gruppi.

Altre informazioni:

È consigliabile usare e includere ruoli dell'app, che i clienti gestiscono usando il portale o le API. Assegnare ruoli a utenti e gruppi per controllare l'accesso. Quando viene rilasciato un token, i ruoli assegnati si trovano nell'attestazione dei ruoli del token. Le informazioni derivate da un token impediscono più chiamate api.

Vedere Aggiungere ruoli app all'applicazione e riceverli nel token

Aggiungere attestazioni in base alle informazioni sul tenant. Ad esempio, un'estensione ha un ID utente specifico dell'organizzazione.

L'aggiunta di informazioni dalla directory a un token è efficiente e aumenta la resilienza riducendo le dipendenze. Non risolve i problemi di resilienza a causa dell'impossibilità di acquisire un token. Aggiungere attestazioni facoltative per gli scenari principali dell'applicazione. Se l'app richiede informazioni per la funzionalità amministrativa, l'applicazione può ottenere tali informazioni, in base alle esigenze.

Microsoft Graph

Microsoft Graph ha un endpoint API unificato per accedere ai dati di Microsoft 365 relativi a modelli di produttività, identità e sicurezza. Le applicazioni che usano Microsoft Graph possono usare le informazioni di Microsoft 365 per l'autorizzazione.

Le app richiedono un token per accedere a Microsoft 365, che è più resiliente rispetto alle API precedenti per i componenti di Microsoft 365 come Microsoft Exchange o Microsoft SharePoint, che richiedono più token.

Quando si usano le API Microsoft Graph, usare Microsoft Graph SDK, che semplifica la creazione di applicazioni resilienti che accedono a Microsoft Graph.

Vedere la panoramica di Microsoft Graph SDK

Per l'autorizzazione, prendere in considerazione l'uso di attestazioni di token anziché di chiamate di Microsoft Graph. Richiedere gruppi, ruoli dell'app e attestazioni facoltative nei token. Per l’autorizzazione, Microsoft Graph richiede più chiamate di rete che si basano su Microsoft Identity Platform e su Microsoft Graph. Tuttavia, se l'applicazione si basa su Microsoft Graph come livello dati, Microsoft Graph per l'autorizzazione non è più rischioso.

Usare l'autenticazione broker nei dispositivi mobili

Nei dispositivi mobili, un broker di autenticazione come Microsoft Authenticator migliora la resilienza. Il broker di autenticazione usa un token di aggiornamento primario (PRT) con attestazioni relative all'utente e al dispositivo. Usare PRT per i token di autenticazione per accedere ad altre applicazioni dal dispositivo. Quando un PRT richiede l'accesso all'applicazione, Microsoft Entra ID considera attendibili le attestazioni del dispositivo e dell'autenticazione a più fattori. In questo modo si aumenta la resilienza riducendo i passaggi per autenticare il dispositivo. Gli utenti non hanno più richieste di autenticazione a più fattori nello stesso dispositivo.

Vedere Che cos'è un token di aggiornamento primario?

Diagramma di un'app che chiama Microsoft Identity Platform tramite una cache dei token, un archivio token e un broker di autenticazione nel dispositivo che esegue l'applicazione.

MSAL supporta l'autenticazione broker. Altre informazioni:

Valutazione continua dell'accesso

La Valutazione continua dell'accesso (CAE) aumenta la sicurezza e la resilienza delle applicazioni con token di lunga durata. Con CAE, un token di accesso viene revocato in base a eventi critici e valutazione dei criteri, anziché a durate di token brevi. Per alcune API delle risorse, poiché i rischi e i criteri vengono valutati in tempo reale, la CAE aumenta la durata dei token fino a 28 ore. MSAL aggiorna i token di lunga durata.

Altre informazioni:

Se si sviluppano API di risorse, passare a openid.net per Segnali condivisi - Framework di webhook sicuri.

Condividi tramite

Aumentare la resilienza di autenticazione e autorizzazione nelle applicazioni client in corso di sviluppo