Procedure consigliate e raccomandazioni per Microsoft Identity Platform
Questo articolo illustre procedure consigliate, raccomandazioni e supervisione comuni durante l'integrazione con Microsoft Identity Platform. Questo elenco di controllo agevola 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 circa l'autenticazione, gli 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 raccomandazioni. 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 riconoscere i Criteri della piattaforma Microsoft. Assicurarsi che l'applicazione rispetti le condizioni indicate, perché sono state 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 della 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à/prodotto in modo che gli utenti possano prendere decisioni informate. Assicurarsi di non violare alcun marchio.
Riservatezza
Fornire collegamenti per le condizioni per l'utilizzo e l'informativa sulla privacy dell'app.
Sicurezza
Gestire gli URI di reindirizzamento:
- Mantenere la proprietà di tutti gli URI di reindirizzamento e assicurare che i rispettivi record DNS siano sempre aggiornati.
- 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, usare 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 troncare tutti gli URI di reindirizzamento non usati o non necessari su base regolare.
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.
Sposta oltre nome utente/password. Non usare flusso di credenziali delle credenziali 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, leggere Flussi di autenticazione e scenari di applicazione.
Proteggere e gestire le credenziali delle app riservate per app Web, API Web e app daemon. Usare le credenziali del certificato invece delle 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 che la gestione venga fatta da persone. Se possibile, usare 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. Riconoscere 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 Microsoft Graph, vedere questo riferimento sulle autorizzazioni.
Se si protegge un'API usando Microsoft Identity Platform, valutare attentamente le autorizzazioni da esporre. Determinare la granularità appropriata per la soluzione e individuare le autorizzazioni che richiedono il consenso 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 Connect) per l'accesso sicuro degli utenti.
Non programmare direttamente su protocolli come OAuth 2.0 e Open ID. Usare invece Microsoft Authentication Library (MSAL). Le librerie MSAL racchiudono in modo sicuro i protocolli di sicurezza in una libreria facile da usare e offrono supporto integrato per scenari di Accesso condizionale, Single Sign-On (SSO) a livello di dispositivo e supporto integrato per la memorizzazione nella cache dei token. Per maggiori informazioni, vedere l'elenco dellelibrerie client supportate da Microsoft. Se è necessario scrivere 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.
NON esaminare il valore del token di accesso o tentare di analizzarlo come client. Possono modificare valori, formati o persino diventare crittografati senza avviso: usare sempre il token ID se il client deve ottenere informazioni sull'utente. Solo le API Web devono analizzare i token di accesso (poiché sono quelli che definiscono il formato e impostano le chiavi di crittografia). L'invio di un token di accesso direttamente a un'API da parte del client è un rischio per la sicurezza, poiché sono credenziali sensibili che concedono l'accesso a determinate risorse. Gli sviluppatori non devono presupporre che il client possa essere considerato attendibile per convalidare il token di accesso.
Eseguire la migrazione di app esistenti da Azure Active Directory Authentication Library (ADAL) a Microsoft Authentication Library. MSAL è la soluzione più recente di Microsoft Identity Platform 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 portale aziendale di Microsoft per informazioni di accesso singolo, l'app necessita che sia configurato un "URI di reindirizzamento broker". Ciò consente a Microsoft di restituire il controllo all'applicazione dopo l'autenticazione. Quando si configura ogni piattaforma, l'esperienza di registrazione dell'app guida attraverso il processo. Usare la guida introduttiva per scaricare un esempio di funzionamento. In iOS usare broker e webview di sistema quando possibile.
Nelle app Web o nelle API Web mantenere una cache di token per account. Per le app Web, la cache di token deve avere la chiave dall'ID account. Per le API Web l'account deve avere la chiave dell'hash del token usato per chiamare l'API. MSAL.NET fornisce la serializzazione della cache di token personalizzata sia in .NET che in .NET Framework. Per motivi di sicurezza e prestazioni, è consigliabile serializzare una cache per utente. Per maggiori informazioni, vedere serializzazione della cache di 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é API singola.
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 quando usa l'app provando a usare l'autenticazione invisibile all'utente (acquisizione di token invisibile all'utente) prima dei flussi interattivi.
Non usare "prompt=consent" per ogni informazioni di 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 consente le attività iniziali.
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 riconoscere perché l'app richiede autorizzazioni che potrebbero creare preoccupazione o confondere gli utenti se richieste al primo avvio.
Implementazione di un'esperienza di disconnessione singola senza problemi. È un requisito di sicurezza e privacy e rende l'esperienza utente ottimale.
Test in corso
Testare i criteri di accesso condizionale che potrebbero 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 per bambini e account sovrani).
Risorse aggiuntive
Approfondimento su v2.0: