Condividi tramite

Autenticazione di applicazioni e utenti con Microsoft Entra ID

Una delle funzioni principali di Microsoft Entra ID per le app è l'autenticazione, ovvero il processo in cui gli utenti dichiarano la propria identità con un identificatore personale, ad esempio un nome utente o un indirizzo di posta elettronica. A tale scopo, viene fornita una prova di identità. Tale prova può consistere in una password, un artefatto di autenticazione a più fattori, un dato biometrico o un consenso senza password.

Questo articolo descrive il modo in cui le applicazioni usano Microsoft Entra ID per autenticare utenti e applicazioni. Si tratta del terzo di una serie di articoli sul modo in cui i fornitori di software indipendenti (ISV) possono creare e ottimizzare le applicazioni per Microsoft Entra ID. In questa serie sono disponibili altre informazioni sugli argomenti seguenti:

Richiedere token

Le applicazioni richiedono un token a Microsoft Entra ID. Dopo aver ricevuto il token, le app possono usare le informazioni in esso contenute per identificare l'utente. Quando si usa Microsoft Entra ID, gli utenti possono autenticare molte applicazioni con un singolo account Microsoft Entra ID (SSO) registrato. Il metodo di autenticazione SSO consente agli utenti di accedere a più sistemi software indipendenti usando un unico set di credenziali.

I protocolli che gli sviluppatori possono usare per richiedere un token a Microsoft Entra ID includono un browser per connettere l'utente al sito Web di Microsoft Entra ID. Questo sito Web consente all'utente di avere una conversazione privata con Microsoft Entra ID. L'applicazione non partecipa alla conversazione privata. Le app avviano il sito Web di Microsoft Entra ID, in cui l'utente inizia il processo di autenticazione. Al termine del processo di autenticazione, Microsoft Entra ID reindirizza l'utente all'applicazione, con o senza token.

È importante che gli utenti debbano eseguire raramente il processo di autenticazione. Maggiore è la frequenza con cui gli utenti devono eseguirlo, tanto più diventano soggetti a exploit come gli attacchi di phishing.

Ridurre le richieste di accesso

L'accesso SSO può ridurre o eliminare le richieste di accesso. Gli sviluppatori svolgono un ruolo fondamentale nella riduzione ed eliminazione delle richieste di accesso. Tutte le app devono condividere il browser che accede al sito Web di Microsoft Entra ID in cui gli utenti eseguono il processo di autenticazione. Se l'app è un'applicazione a singola pagina (SPA) basata su browser o un'app Web, non sono richiesti passaggi da parte degli sviluppatori. Tutte le app del browser condividono il browser. Per le applicazioni native eseguite su desktop e dispositivi mobili, gli sviluppatori devono ridurre o eliminare in modo proattivo le richieste di accesso.

II metodo migliore per ridurre o eliminare le richieste di accesso consiste nell'usare Microsoft Authentication Libraries (MSAL), oppure una libreria basata su MSAL e le autenticazioni del broker. Questo metodo riduce al minimo le richieste di accesso e offre un'esperienza ottimale. Se non è possibile usare MSAL, l'applicazione deve ricorrere al browser di sistema per ridurre al minimo le richieste di accesso.

Per le app in esecuzione in iOS o Android, i provider di piattaforme mobili dispongono di alcune funzionalità per rendere questa esperienza più fluida. Google offre indicazioni per le applicazioni Android con le schede personalizzate di Chrome. Apple offre indicazioni per l’autenticazione di un utente tramite un servizio Web nelle applicazioni iOS. Evitare l'uso di WebView incorporate, in quanto potrebbero non consentire la condivisione tra app o con il browser di sistema.

I due protocolli per l'autenticazione degli utenti sono Security Assertion Markup Language (SAML) 2.0 e OpenID Connect (OIDC). Microsoft Entra ID supporta completamente le app che usano entrambi i protocolli, in modo che gli sviluppatori possano scegliere l'uno o l'altro in base alle loro esigenze.

Questi riferimenti illustrano in dettaglio il supporto SAML di Microsoft Entra ID.

Esistono alcune limitazioni nel supporto SAML di Microsoft Entra ID. In particolare, non è possibile eseguire la migrazione di app che richiedono le funzionalità del protocollo seguenti: supporto per il modello WS-Trust ActAs e risoluzione degli artefatti SAML.

Sebbene Microsoft Entra ID supporti completamente SAML per le app basate sul protocollo SAML, Microsoft Identity Platform non fornisce librerie o altri strumenti di sviluppo per la realizzazione di applicazioni con SAML. Per lo sviluppo di nuove applicazioni, è consigliabile usare OpenID Connect (OIDC) per l'autenticazione.

Microsoft Entra ID supporta completamente OpenID Connect. Microsoft offre librerie MSAL, Microsoft Identity Web e Azure SDK per semplificare lo sviluppo di applicazioni OIDC. OpenID Connect (OIDC) in Microsoft Identity Platformfornisce dettagli sul supporto OIDC di Microsoft Entra ID. MSAL supporta automaticamente OIDC. MSAL richiede sempre un token ID OIDC per ogni richiesta di token, incluse le richieste di autorizzazione per l'accesso di un'app a una risorsa.

Durata dei token

MSAL memorizza nella cache i token ID e i token di accesso in base all'ora di scadenza del token di accesso. Poiché Microsoft Entra ID imposta in modo diverso la durata dei token ID e dei token di accesso, è possibile che si riceva un token ID scaduto da una cache MSAL scaduta mentre il token di accesso ha ancora una durata valida.

MSAL non rinnova automaticamente i token ID. MSAL rinnova i token di accesso alla termine del ciclo di vita del token di accesso, o in prossimità di tale scadenza, quando un'applicazione richiede il token. A questo punto, MSAL richiede un nuovo token ID. Per implementare OIDC, usare l'expattestazione (expire) nel token ID per pianificare una richiesta di token ID usando il flag ForceRefreshin MSAL.

Quando non è possibile usare MSAL o una libreria basata su MSAL, lo standard OpenID Connect può essere usato per autenticare l'utente corrente. Alcune funzionalità delle applicazioni native potrebbero non essere possibili senza l'uso di MSAL, ad esempio la verifica che l'app nativa sia in esecuzione in un dispositivo gestito. Vedere Aumentare la resilienza di autenticazione e autorizzazione nelle applicazioni client in corso di sviluppo per indicazioni quando non si esegue la compilazione in MSAL.

Microsoft Entra ID implementa un endpoint UserInfo come parte del supporto degli standard OIDC di Microsoft Entra ID con un percorso Microsoft Graph specifico (https://graph.microsoft.com/oidc/userinfo). Non è possibile aggiungere o personalizzare le informazioni restituite dall'endpoint UserInfo. Poiché le informazioni contenute nel token ID costituiscono un superset delle informazioni restituite dalla chiamata all'endpoint UserInfo, è consigliabile usare il token ID anziché chiamare l'endpointUserInfo.

Autenticare gli utenti

Le applicazioni interagiscono con i tenant di Microsoft Entra ID per autenticare gli utenti. Per autenticare un utente, un'applicazione indirizza un browser a https://login.microsoftonline.com/{tenant}/v2.0, in cui {tenant} è l'ID o il dominio del tenant. È tuttavia consigliabile che gli ISV usino Microsoft Entra ID per creare applicazioni multi-tenant in grado di supportare la più ampia gamma di clienti. Per un'applicazione multi-tenant, un'app potrebbe non sapere da quale tenant proviene un utente fino a quando l'utente non esegue l'autenticazione, quindi non è possibile usare un endpoint tenant specifico.

Per abilitare le app multi-tenant, Microsoft Entra ID fornisce due endpoint OIDC/OAuth 2.0 indipendenti dal tenant:

  • https://login.microsoftonline.com/common/v2.0 consente agli utenti di autenticare un'app se provengono da un qualsiasi tenant di Microsoft Entra ID o se dispongono di un account Microsoft consumer da siti come outlook.com, skype.com, xbox.com, live.com o Hotmail.com.
  • https://login.microsoftonline.com/organizations/v2.0 consente agli utenti di autenticare un'app quando provengono da qualsiasi tenant di Microsoft Entra ID.

Questi endpoint consentono agli utenti di qualsiasi tenant Microsoft Entra ID di autenticare l'applicazione. Se si vuole consentire l'accesso solo agli utenti di tenant specifici, implementare la logica per permettere agli utenti di tali tenant di accedere all'app. L'implementazione normale consiste nel filtrare gli utenti in base all'attestazione iss (autorità di certificazione) o tid (ID tenant) nel token in un elenco di tenant consentiti gestiti.

I tenant di Microsoft Entra ID supportano utenti che possono essere membri regolari del tenant o utenti guest del tenant. Per impostazione predefinita, sono disponibili funzionalità limitate per gli utenti guest in un tenant. Ad esempio, gli utenti guest non possono visualizzare il profilo completo di altri utenti nel tenant. Gli utenti guest, talvolta denominati utenti Business to Business (B2B), consentono a organizzazioni diverse di collaborare con strumenti e servizi protetti da Microsoft Entra ID. Uno scenario di esempio consiste nell'invitare un utente esterno all'organizzazione ad accedere a un file SharePoint nel tenant. In genere, un utente B2B usa il proprio indirizzo di posta elettronica come userid. Può tuttavia usare lo stesso indirizzo come userid nel tenant principale. Per impostazione predefinita, Microsoft Entra ID consente all'utente di accedere al tenant principale quando lo immette nel proprio userid.

Per accedere a un utente come utente B2B, un'applicazione deve usare l'endpoint del tenant specifico in cui l'utente è un guest. Sebbene sia possibile per un utente specificare il tenant a cui vuole accedere quando un'applicazione usa l'endpoint https://login.microsoftonline.com/organizations/v2.0, potrebbe trovare difficile individuare questa funzionalità.

Passaggi successivi