Procedure consigliate e raccomandazioni per Microsoft Identity Platform

Questo articolo illustra procedure consigliate, raccomandazioni e supervisione comuni durante l'integrazione con Microsoft Identity Platform. Questo elenco di controllo ti guiderà a un'integrazione di alta qualità e sicura. Esaminare regolarmente questo elenco per assicurarsi di mantenere la qualità e la sicurezza dell'integrazione dell'app con Identity Platform. L'elenco di controllo non è progettato per esaminare l'intera applicazione. Il contenuto dell'elenco di controllo è soggetto a modifiche man mano che vengono apportati miglioramenti alla piattaforma.

Per iniziare, vedere la documentazione di Microsoft Identity Platform per informazioni sulle nozioni di base sull'autenticazione, sugli scenari di applicazione in Microsoft Identity Platform e altro ancora.

Usare l'elenco di controllo seguente per assicurarsi che l'applicazione sia effettivamente integrata con Microsoft Identity Platform.

Suggerimento

L'Assistente integrazione consente di applicare molte di queste procedure consigliate e consigli. Selezionare una delle registrazioni dell'app e quindi selezionare la voce di menu Assistente integrazione per iniziare a usare l'assistente.

Nozioni di base

Leggere e comprendere i criteri della piattaforma Microsoft. Assicurarsi che l'applicazione sia conforme alle condizioni descritte come progettate per proteggere gli utenti e la piattaforma.

Proprietà

Assicurarsi che le informazioni associate all'account usato per registrare e gestire le app siano aggiornate.

Personalizzazione

Rispettare le linee guida sulla personalizzazione per le applicazioni.

Specificare un nome e un logo significativi per l'applicazione. Queste informazioni vengono visualizzate nella richiesta di consenso dell'applicazione. Assicurarsi che il nome e il logo siano rappresentativi della società o del prodotto in modo che gli utenti possano prendere decisioni informate. Assicurarsi di non violare alcun marchio.

Riservatezza

Fornire collegamenti alle condizioni per il servizio e all'informativa sulla privacy dell'app.

Sicurezza

Gestire gli URI di reindirizzamento:

• Mantenere la proprietà di tutti gli URI di reindirizzamento e mantenere aggiornati i record DNS.
• Non usare caratteri jolly (*) negli URI.
• Per le app Web, assicurarsi che tutti gli URI siano protetti e crittografati (ad esempio, usando schemi HTTPS).
• Per i client pubblici, usare URI di reindirizzamento specifici della piattaforma, se applicabile (principalmente per iOS e Android). In caso contrario, usa gli URI di reindirizzamento con una quantità elevata di casualità per evitare conflitti durante la chiamata all'app.
• Se l'app viene usata da un agente Web isolato, è possibile usare https://login.microsoftonline.com/common/oauth2/nativeclient.
• Esaminare e tagliare regolarmente tutti gli URI di reindirizzamento inutilizzati o non necessari.

Se l'app è registrata in una directory, ridurre al minimo e monitorare manualmente l'elenco dei proprietari della registrazione dell'app.

Non abilitare il supporto per il flusso di concessione implicita OAuth2, a meno che non sia richiesto in modo esplicito. Informazioni sullo scenario valido qui.

Spostarsi oltre il nome utente/password. Non usare il flusso di credenziali della password del proprietario della risorsa (ROPC) che gestisce direttamente le password degli utenti. Questo flusso richiede un elevato livello di attendibilità e di esposizione degli utenti e deve essere usato solo quando non è possibile usare altri flussi più sicuri. Questo flusso è ancora necessario in alcuni scenari (ad esempio, DevOps), ma tenere presente che l'uso di questa funzione imporrà vincoli sull'applicazione. Per approcci più moderni, vedere Flussi di autenticazione e scenari di applicazione.

Proteggere e gestire le credenziali dell'app riservata per app Web, API Web e app daemon. Usare le credenziali del certificato, non le credenziali password (segreti client). Se è necessario usare una credenziale password, non impostarla manualmente. Non archiviare le credenziali nel codice o nella configurazione e non consentire mai di gestirle dagli esseri umani. Se possibile, usare le identità gestite per le risorse di Azure o Azure Key Vault per archiviare e ruotare regolarmente le credenziali.

Assicurarsi che l'applicazione richieda le autorizzazioni con privilegi minimi. Chiedere solo le autorizzazioni necessarie all'applicazione e solo quando sono necessarie. Comprendere i diversi tipi di autorizzazioni. Usare solo le autorizzazioni dell'applicazione, se necessario; usare le autorizzazioni delegate laddove possibile. Per un elenco completo delle autorizzazioni di Microsoft Graph, vedere le informazioni di riferimento sulle autorizzazioni.

Se si protegge un'API usando Microsoft Identity Platform, valutare attentamente le autorizzazioni da esporre. Considerare qual è la granularità corretta per la soluzione e quali autorizzazioni richiedono il consenso dell'amministratore. Verificare la presenza di autorizzazioni previste nei token in ingresso prima di prendere decisioni di autorizzazione.

Implementazione

Usare soluzioni di autenticazione moderne (OAuth 2.0, OpenID Connessione) per accedere in modo sicuro agli utenti.

Non programmare direttamente su protocolli come OAuth 2.0 e Open ID. Usare invece Microsoft Authentication Library (MSAL). Le librerie MSAL incapsulare in modo sicuro i protocolli di sicurezza in una libreria facile da usare e si ottiene il supporto predefinito per gli scenari di accesso condizionale, l'accesso Single Sign-On (SSO) a livello di dispositivo e il supporto predefinito per la memorizzazione nella cache dei token. Per altre informazioni, vedi l'elenco delle librerie client supportate da Microsoft. Se è necessario completare il codice manuale per i protocolli di autenticazione, è necessario seguire microsoft SDL o una metodologia di sviluppo simile. Prestare particolare attenzione alle considerazioni sulla sicurezza nelle specifiche degli standard per ogni protocollo.

Eseguire la migrazione di app esistenti da Azure Active Directory Authentication Library (ADAL) a Microsoft Authentication Library. MSAL è la soluzione più recente di Identity Platform di Microsoft ed è disponibile in .NET, JavaScript, Android, iOS, macOS, Python e Java. Altre informazioni sulla migrazione di app broker ADAL.NET, ADAL.js e ADAL.NET e iOS .

Per le app per dispositivi mobili, configurare ogni piattaforma usando l'esperienza di registrazione dell'applicazione. Per consentire all'applicazione di sfruttare i vantaggi di Microsoft Authenticator o Microsoft Portale aziendale per l'accesso Single Sign-In, l'app necessita di un "URI di reindirizzamento broker" configurato. Ciò consente a Microsoft di restituire il controllo all'applicazione dopo l'autenticazione. Quando si configura ogni piattaforma, l'esperienza di registrazione dell'app ti guiderà attraverso il processo. Usare la guida introduttiva per scaricare un esempio funzionante. In iOS usare broker e webview di sistema quando possibile.

Nelle app Web o nelle API Web mantenere una cache dei token per account. Per le app Web, la cache dei token deve essere chiaveta dall'ID account. Per le API Web, l'account deve essere chiaveto dall'hash del token usato per chiamare l'API. MSAL.NET fornisce la serializzazione della cache dei token personalizzata sia in .NET che in .NET Framework. Per motivi di sicurezza e prestazioni, è consigliabile serializzare una cache per utente. Per altre informazioni, vedere Serializzazione della cache dei token.

Se i dati richiesti dall'app sono disponibili tramite Microsoft Graph, richiedere le autorizzazioni per questi dati usando l'endpoint di Microsoft Graph anziché l'API singola.

Non esaminare il valore del token di accesso o tentare di analizzarlo come client. Possono modificare valori, formati o persino essere crittografati senza avviso. Usare sempre il id_token se il client deve ottenere informazioni sull'utente o chiamare Microsoft Graph. Solo le API Web devono analizzare i token di accesso (poiché sono quelli che definiscono il formato e impostano le chiavi di crittografia).

Esperienza utente finale

Comprendere l'esperienza di consenso e configurare le parti della richiesta di consenso dell'app in modo che gli utenti finali e gli amministratori dispongano di informazioni sufficienti per determinare se considerano attendibile l'app.

Ridurre al minimo il numero di volte in cui un utente deve immettere le credenziali di accesso durante l'uso dell'app provando l'autenticazione invisibile all'utente (acquisizione di token invisibile all'utente) prima dei flussi interattivi.

Non usare "prompt=consent" per ogni accesso. Usare prompt=consent solo se si è determinato che è necessario chiedere il consenso per ottenere autorizzazioni aggiuntive, ad esempio se sono state modificate le autorizzazioni necessarie per l'app.

Se applicabile, arricchire l'applicazione con i dati utente. L'uso dell'API Microsoft Graph è un modo semplice per eseguire questa operazione. Lo strumento Graph Explorer che consente di iniziare.

Registrare il set completo di autorizzazioni richieste dall'app in modo che gli amministratori possano concedere facilmente il consenso al tenant. Usare il consenso incrementale in fase di esecuzione per aiutare gli utenti a capire perché l'app richiede autorizzazioni che potrebbero riguardare o confondere gli utenti quando richiesto al primo avvio.

Implementare un'esperienza di single sign-out pulita. Si tratta di una privacy e di un requisito di sicurezza e rende un'esperienza utente ottimale.

Test in corso

Testare i criteri di accesso condizionale che possono influire sulla capacità degli utenti di usare l'applicazione.

Testare l'applicazione con tutti gli account possibili che si prevede di supportare (ad esempio, account aziendali o dell'istituto di istruzione, account Microsoft personali, account figlio e account sovrani).

Risorse aggiuntive

Approfondimento su v2.0:

• Microsoft Identity Platform (panoramica)
• Informazioni di riferimento su protocolli di Microsoft Identity Platform
• Riferimento ai token di accesso
• Informazioni di riferimento sui token ID
• Informazioni di riferimento sulle librerie di autenticazione
• Autorizzazioni e consenso in Microsoft Identity Platform
• API di Microsoft Graph