Flussi di autenticazione supportati in MSAL

Microsoft Authentication Library (MSAL) supporta diverse concessioni di autorizzazione e flussi di token associati per l'uso da diversi tipi di applicazioni e scenari.

Flusso di autenticazione	Consente	Tipi di applicazione supportati
Codice di autorizzazione	L'accesso utente e l'accesso alle API Web per conto dell'utente.	* Desktop * Dispositivi mobili * App a pagina singola (SPA) (richiede PKCE) * Web
Credenziali del client	Accesso alle API Web usando l'identità dell'applicazione stessa. In genere usato per la comunicazione da server a server e script automatizzati che non richiedono alcuna interazione dell'utente.	Daemon
Codice del dispositivo	Accesso utente e accesso alle API Web per conto dell'utente su dispositivi con vincoli di input, ad esempio dispositivi SMART TV e Internet delle cose (IoT). Usato anche dalle applicazioni dell'interfaccia della riga di comando.	Desktop, Mobile
Concessione implicita	Accesso utente e accesso alle API Web per conto dell'utente. Il flusso di concessione implicita non è più consigliato. Usare invece il codice di autorizzazione con la chiave di prova per Lo scambio di codice (PKCE).	* App a pagina singola * Web
On-behalf-of (OBO)	Accesso da un'API Web "upstream" a un'API Web "downstream" per conto dell'utente. L'identità e le autorizzazioni delegate dell'utente vengono passate all'API downstream dall'API upstream.	API Web
Nome utente/password (ROPC)	Consente a un'applicazione di eseguire l'accesso dell'utente gestendone direttamente la password. Il flusso ROPC non è consigliato.	Desktop, Mobile
Integrated autenticazione di Windows (IWA)	Consente alle applicazioni nei computer aggiunti a un dominio o a Microsoft Entra ID di acquisire automaticamente un token (senza alcuna interazione dell'interfaccia utente dall'utente).	Desktop, Mobile

OAuth

L'applicazione può usare uno o più flussi di autenticazione. Ogni flusso usa determinati tipi di token per l'autenticazione, l'autorizzazione e l'aggiornamento del token e alcuni usano anche un codice di autorizzazione.

Flusso o azione di autenticazione	Richiede	token ID	Token di accesso	token di aggiornamento	Codice di autorizzazione
Flusso del codice di autorizzazione		✅	✅	✅	✅
Credenziali del client			✅ (solo app)
Flusso del codice del dispositivo		✅	✅	✅
Flusso implicito		✅	✅
Flusso on-behalf-of	Token di accesso	✅	✅	✅
Nome utente/password (ROPC)	Nome utente, password	✅	✅	✅
Flusso OIDC ibrido		✅			✅
Riscatto del token di aggiornamento	token di aggiornamento	✅	✅	✅

Autenticazione interattiva e non interattiva

Molti di questi flussi supportano l'acquisizione di token interattivi e non interattivi.

• Interattivo : l'utente può richiedere l'input dal server di autorizzazione. Ad esempio, per accedere, eseguire l'autenticazione a più fattori (MFA) o concedere il consenso a più autorizzazioni di accesso alle risorse.
• Non interattivo : l'utente potrebbe non essere richiesto per l'input. Chiamata anche acquisizione di token invisibile all'utente, l'applicazione tenta di ottenere un token usando un metodo in cui il server di autorizzazione potrebbe non richiedere l'input all'utente.

L'applicazione basata su MSAL deve prima provare ad acquisire un token in modo invisibile all'utente ed eseguire il fallback al metodo interattivo solo se il tentativo non interattivo ha esito negativo. Per altre informazioni su questo modello, vedere Acquisire e memorizzare nella cache i token con Microsoft Authentication Library (MSAL).For more information about this pattern, see Acquire and cache tokens using the Microsoft Authentication Library (MSAL).

Codice di autorizzazione

La concessione del codice di autorizzazione OAuth 2.0 può essere usata dalle app Web, dalle app a pagina singola (SPA) e dalle applicazioni native (per dispositivi mobili e desktop) per ottenere l'accesso a risorse protette come le API Web.

Quando gli utenti accedono alle applicazioni Web, l'applicazione riceve un codice di autorizzazione che può riscattare per un token di accesso per chiamare le API Web.

Nel diagramma precedente, l'applicazione:

1. Richiede un codice di autorizzazione riscattato per un token di accesso.
2. Usa il token di accesso per chiamare un'API Web, ad esempio Microsoft Graph.

Vincoli per il codice di autorizzazione

• Le applicazioni a pagina singola richiedono la chiave di prova per Lo scambio di codice (PKCE) quando si usa il flusso di concessione del codice di autorizzazione. PKCE è supportato da MSAL.

• La specifica OAuth 2.0 richiede l'uso di un codice di autorizzazione per riscattare un token di accesso una sola volta.

  Se si tenta di acquisire più volte un token di accesso con lo stesso codice di autorizzazione, viene restituito un errore simile al seguente da Microsoft Identity Platform. Tenere presente che alcune librerie e framework richiedono automaticamente il codice di autorizzazione e la richiesta manuale di un codice in questi casi genererà anche questo errore.

  AADSTS70002: Error validating credentials. AADSTS54005: OAuth2 Authorization code was already redeemed, please retry with a new valid code or use an existing refresh token.

Credenziali del client

Il flusso di credenziali client OAuth 2 consente di accedere alle risorse ospitate sul Web usando l'identità di un'applicazione. Questo tipo di concessione viene comunemente usato per le interazioni da server a server (S2S) che devono essere eseguite in background, senza interazione immediata da parte di un utente. Questi tipi di applicazioni vengono spesso definiti daemon o servizi.

Il flusso di concessione delle credenziali client consente a un servizio Web (client riservato) di usare le proprie credenziali, invece di rappresentare un utente, per l'autenticazione durante la chiamata a un altro servizio Web. In questo scenario il client è in genere un servizio Web di livello intermedio, un servizio Daemon o un sito Web. Per un livello più elevato di sicurezza, Microsoft Identity Platform consente anche al servizio chiamante di usare un certificato (invece di un segreto condiviso) come credenziale.

Segreti dell'applicazione

Nel diagramma precedente, l'applicazione:

1. Acquisisce un token usando un segreto dell'applicazione o le credenziali della password.
2. Usa il token per effettuare richieste di risorse.

Certificati

Nel diagramma precedente, l'applicazione:

1. Acquisisce un token usando le credenziali del certificato.
2. Usa il token per effettuare richieste di risorse.

Questo tipo di credenziali client deve essere:

• Registrate con Azure AD.
• Passato durante la costruzione dell'oggetto applicazione client riservato nel codice.

Vincoli per le credenziali client

Il flusso del client riservato non è supportato su piattaforme mobili come Android, iOS o piattaforma UWP (Universal Windows Platform) (UWP). Le applicazioni per dispositivi mobili sono considerate applicazioni client pubbliche che non sono in grado di garantire la riservatezza dei segreti di autenticazione.

Codice del dispositivo

Il flusso di codice del dispositivo OAuth 2 consente agli utenti di accedere a dispositivi vincolati di input come televisori intelligenti, dispositivi IoT (Internet delle cose) e stampanti. L'autenticazione interattiva con Microsoft Entra ID richiede un Web browser. Se il dispositivo o il sistema operativo non fornisce un Web browser, il flusso del codice del dispositivo consente di usare un altro dispositivo, ad esempio un computer o un telefono cellulare, per accedere in modo interattivo.

Usando il flusso del codice del dispositivo, l'applicazione ottiene i token tramite un processo in due passaggi progettato per questi dispositivi e sistemi operativi.

Nel diagramma precedente:

1. Ogni volta che è necessaria l'autenticazione utente, l'app fornisce un codice e chiede all'utente di usare un altro dispositivo come uno smartphone connesso a Internet per visitare un URL (ad esempio, https://microsoft.com/devicelogin). All'utente viene quindi richiesto di immettere il codice e procedere con una normale esperienza di autenticazione, incluse le richieste di consenso e l'autenticazione a più fattori, se necessario.
2. Al termine dell'autenticazione, l'applicazione richiedente riceve i token necessari da Microsoft Identity Platform e li usa per eseguire le chiamate API Web necessarie.

Vincoli per il codice del dispositivo

• Il flusso del codice del dispositivo è disponibile solo per le applicazioni client pubbliche.
• Quando si inizializza un'applicazione client pubblica in MSAL, usare uno di questi formati di autorità:
  • Basato sul tenant: https://login.microsoftonline.com/{tenant}/, dove {tenant} è il GUID che rappresenta l'ID tenant o un nome di dominio associato al tenant.
  • Account aziendali e dell'istituto di istruzione: https://login.microsoftonline.com/organizations/.

Concessione implicita

La concessione implicita è stata sostituita dal flusso del codice di autorizzazione con PKCE come flusso di concessione di token preferito e più sicuro per le applicazioni a pagina singola sul lato client. Se si sta creando un'applicazione a pagina singola, usare invece il flusso del codice di autorizzazione con PKCE.

Le app Web a pagina singola scritte in JavaScript (inclusi framework come Angular, Vue.js o React.js) vengono scaricate dal server e il relativo codice viene eseguito direttamente nel browser. Poiché il codice lato client viene eseguito nel browser e non in un server Web, hanno caratteristiche di sicurezza diverse rispetto alle applicazioni Web sul lato server tradizionali. Prima della disponibilità di Proof Key for Code Exchange (PKCE) per il flusso del codice di autorizzazione, il flusso di concessione implicita è stato usato dai provider di servizi di sicurezza per migliorare la velocità di risposta e l'efficienza per ottenere i token di accesso.

Il flusso di concessione implicita OAuth 2 consente all'app di ottenere token di accesso da Microsoft Identity Platform senza eseguire uno scambio di credenziali del server back-end. Il flusso di concessione implicita consente a un'app di accedere all'utente, gestire una sessione e ottenere i token per altre API Web dall'interno del codice JavaScript scaricato ed eseguito dall'agente utente (in genere un Web browser).

Vincoli per la concessione implicita

Il flusso di concessione implicita non include scenari di applicazione che usano framework JavaScript multipiattaforma come Electron o React Native. I framework multipiattaforma come questi richiedono funzionalità aggiuntive per l'interazione con le piattaforme desktop e per dispositivi mobili native in cui vengono eseguite.

I token rilasciati tramite la modalità di flusso implicita presentano una limitazione di lunghezza perché vengono restituiti al browser nell'URL (dove response_mode è query o fragment). Alcuni browser limitano la lunghezza dell'URL nella barra del browser e hanno esito negativo quando è troppo lungo. Di conseguenza, questi token di flusso impliciti non contengono groups o wids attestazioni.

On-behalf-of (OBO)

Il flusso del flusso di autenticazione on-behalf-of OAuth 2 viene usato quando un'applicazione richiama un servizio o un'API Web che a sua volta deve chiamare un altro servizio o UN'API Web usando un'identità utente delegata e autorizzazioni che devono propagarsi attraverso la catena di richieste. Affinché il servizio di livello intermedio esegua richieste autenticate al servizio downstream, deve proteggere un token di accesso da Microsoft Identity Platform per conto dell'utente richiedente.

Nel diagramma precedente:

1. L'applicazione acquisisce un token di accesso per l'API Web.
2. Un client (Web, desktop, mobile o applicazione a pagina singola) chiama un'API Web protetta, aggiungendo il token di accesso come bearer token nell'intestazione di autenticazione della richiesta HTTP. L'API Web autentica l'utente.
3. Quando il client chiama l'API Web, l'API Web richiede un altro token per conto dell'utente.
4. L'API Web protetta usa questo token per chiamare un'API Web downstream per conto dell'utente. L'API Web può anche richiedere in seguito token per altre API downstream (ma ancora per conto dello stesso utente).

Nome utente/password (ROPC)

Avviso

Il flusso delle credenziali della password del proprietario della risorsa (ROPC) non è più consigliato. ROPC richiede un elevato livello di attendibilità e esposizione delle credenziali. Usare ROPC solo se non è possibile usare un flusso più sicuro. Per altre informazioni, vedere Qual è la soluzione per il problema crescente delle password?.

La concessione delle credenziali della password del proprietario della risorsa OAuth 2 (ROPC) consente a un'applicazione di accedere all'utente gestendo direttamente la password. Nell'applicazione desktop è possibile usare il flusso nome utente/password per acquisire un token in modo invisibile all'utente. Quando si usa l'applicazione non è necessaria l'interfaccia utente.

Alcuni scenari di applicazione, ad esempio DevOps, potrebbero risultare utili per ROPC, ma è consigliabile evitarlo in qualsiasi applicazione in cui si fornisce un'interfaccia utente interattiva per l'accesso utente.

Nel diagramma precedente, l'applicazione:

1. Acquisisce un token inviando il nome utente e la password al provider di identità.
2. Chiama un'API Web usando il token.

Per acquisire un token in modo invisibile all'utente nei computer windows aggiunti a un dominio, è consigliabile usare Web Account Manager (WAM) anziché ROPC. Per altri scenari, usare il flusso di codice del dispositivo.

Vincoli per ROPC

I vincoli seguenti si applicano alle applicazioni che usano il flusso ROPC:

• Single Sign-On non è supportato.
• L'autenticazione a più fattori (MFA) non è supportata.
  • Prima di usare questo flusso, rivolgersi all'amministratore del tenant. L'autenticazione a più fattori è una funzionalità comunemente usata.
• L'accesso condizionale non è supportato.
• ROPC funziona solo per gli account aziendali e dell'istituto di istruzione.
• Gli account Microsoft personali non sono supportati da ROPC.
• ROPC è supportato nelle applicazioni desktop .NET e .NET.
• ROPC non è supportato nelle applicazioni piattaforma UWP (Universal Windows Platform) (UWP).
• ROPC in Microsoft Entra per ID esterno è supportato solo per gli account locali.
  • Per informazioni su ROPC in MSAL.NET e Microsoft Entra per ID esterno, vedere Resource Owner Password Credentials (ROPC) With B2C (Resource Owner Password Credentials) with B2C (Credenziali della password del proprietario della risorsa con B2C).

Integrated autenticazione di Windows (IWA)

Nota

L'autenticazione integrata di Windows è stata sostituita con un modo più affidabile per ottenere i token in modo invisibile all'utente: WAM. WAM può accedere automaticamente all'utente corrente di Windows. Questo flusso di lavoro non richiede una configurazione complessa e funziona anche per gli account personali (Microsoft). Internamente, Windows Broker (WAM) tenterà diverse strategie per ottenere un token per l'utente di Windows corrente, tra cui IWA e riscattando il token pull. In questo modo si elimina la maggior parte delle limitazioni con IWA.

MSAL supporta autenticazione di Windows integrate (IWA) per applicazioni desktop e per dispositivi mobili eseguite in computer Windows aggiunti a un dominio o aggiunti a Microsoft Entra ID. Usando IWA, queste applicazioni acquisiscono automaticamente un token senza richiedere l'interazione dell'interfaccia utente da parte dell'utente.

Nel diagramma precedente, l'applicazione:

1. Acquisisce un token con l'autenticazione integrata di Windows.
2. Usa il token per effettuare richieste di risorse.

Vincoli per IWA

• Compatibilità. L'autenticazione di Windows integrata è abilitata per le app .NET desktop, .NET e piattaforma UWP (Universal Windows Platform) (UWP). IWA supporta solo gli utenti federati ADFS: utenti creati in Active Directory e supportati da Microsoft Entra ID. Gli utenti creati direttamente in Microsoft Entra ID senza supporto di Active Directory (utenti gestiti) non possono usare questo flusso di autenticazione.
• Multi-Factor Authentication (MFA). L'autenticazione non interattiva (invisibile all'utente) di IWA può non riuscire se l'autenticazione MFA è abilitata nel tenant microsoft Entra ID e viene generata una richiesta di autenticazione MFA da Microsoft Entra ID. In caso di errore di IWA, è consigliabile eseguire il fallback a un metodo interattivo di autenticazione , come descritto in precedenza. Microsoft Entra ID usa l'intelligenza artificiale per determinare quando è necessaria l'autenticazione a due fattori. L'autenticazione a due fattori è in genere necessaria quando un utente accede da un paese o un'area geografica diversa, quando si è connessi a una rete aziendale senza usare una VPN e talvolta quando sono connessi tramite una VPN. Poiché la configurazione e la frequenza di verifica dell'autenticazione a più fattori potrebbero non essere al di fuori del controllo dello sviluppatore, l'applicazione deve gestire correttamente un errore di acquisizione del token invisibile all'utente di IWA.
• Restrizioni relative all'URI dell'autorità. L'autorità passata durante la costruzione dell'applicazione client pubblica deve essere una delle seguenti:
  • https://login.microsoftonline.com/{tenant}/ - Questa autorità indica un'applicazione a tenant singolo il cui gruppo di destinatari di accesso è limitato agli utenti nel tenant specificato di Microsoft Entra ID. Il {tenant} valore può essere l'ID tenant in formato GUID o il nome di dominio associato al tenant.
  • https://login.microsoftonline.com/organizations/ - Questa autorità indica un'applicazione multi-tenant i cui destinatari di accesso sono utenti in qualsiasi tenant di Microsoft Entra ID.
• Account personali. I valori di autorità non devono contenere /common o /consumers perché gli account Microsoft personali non sono supportati da IWA.
• Requisiti di consenso. Poiché IWA è un flusso invisibile all'utente, l'utente dell'applicazione deve aver precedentemente acconsentito all'uso dell'applicazione o l'amministratore del tenant deve aver precedentemente concesso il consenso a tutti gli utenti del tenant per usare l'applicazione. Per soddisfare entrambi i requisiti, è necessario che una di queste operazioni sia stata completata:
  • Lo sviluppatore dell'applicazione ha selezionato Concedi nel portale di Azure per se stessi.
  • Un amministratore tenant ha selezionato Concedi/revoca il consenso amministratore per {dominio tenant} nella scheda Autorizzazioni API della registrazione dell'app nel portale di Azure. Vedere Aggiungere autorizzazioni per accedere all'API Web.
  • È stato fornito un modo per consentire agli utenti di fornire il consenso all'applicazione; Vedere Panoramica delle autorizzazioni e del consenso in Microsoft Identity Platform.
  • È stato fornito un modo per consentire all'amministratore del tenant di fornire il consenso per l'applicazione; Vedere Panoramica delle autorizzazioni e del consenso in Microsoft Identity Platform.

Passaggi successivi

Dopo aver esaminato i flussi di autenticazione supportati da MSAL, è possibile acquisire e memorizzare nella cache i token usati in questi flussi.