Supporto del flusso di autenticazione in MSAL

  • Articolo

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 Accesso utente e 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 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 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 di acquisire automaticamente un token (senza alcuna interazione dell'interfaccia utente dell'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 Il flusso di autenticazione funziona per il token ID Il flusso di autenticazione funziona per il token di accesso Il flusso di autenticazione funziona per il token di aggiornamento Il codice di autorizzazione funziona
Credenziali del client Il flusso di autenticazione funziona per il token di accesso (solo app)
Flusso del codice del dispositivo Il flusso di autenticazione funziona per il token ID Il flusso di autenticazione funziona per il token di accesso Il flusso di autenticazione funziona per il token di aggiornamento
Flusso implicito Il flusso di autenticazione funziona per il token ID Il flusso di autenticazione funziona per il token di accesso
Flusso on-behalf-of token di accesso Il flusso di autenticazione funziona per il token ID Il flusso di autenticazione funziona per il token di accesso Il flusso di autenticazione funziona per il token di aggiornamento
Nome utente/password (ROPC) username, password Il flusso di autenticazione funziona per il token ID Il flusso di autenticazione funziona per il token di accesso Il flusso di autenticazione funziona per il token di aggiornamento
Flusso OIDC ibrido Il flusso di autenticazione funziona per il token ID Il codice di autorizzazione funziona
Riscatto del token di aggiornamento token di aggiornamento Il flusso di autenticazione funziona per il token ID Il flusso di autenticazione funziona per il token di accesso Il flusso di autenticazione funziona per il 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 (invisibile all'utente): potrebbe non essere richiesto 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 app 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 seguente 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, Microsoft Graph

Diagramma del flusso del codice di autorizzazione.

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 il token di accesso con lo stesso codice di autorizzazione, viene restituito un errore simile al seguente da Microsoft Identity Platform. 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.0 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 che devono essere eseguite in background, senza l'interazione immediata con un utente. Questo tipo di applicazioni viene spesso definito daemon o account di servizio.

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 seguente l'applicazione:

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

Diagramma del client riservato con password.

Attestati

Nel diagramma seguente l'applicazione:

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

Diagramma del client riservato con certificato.

Queste credenziali client devono essere:

  • Registrato con Microsoft Entra ID
  • Passato durante la costruzione dell'oggetto applicazione client riservato nel codice

Vincoli per le credenziali client

Il flusso client riservato non è supportato su piattaforme mobili come Android, iOS o UWP. Le applicazioni per dispositivi mobili sono considerate applicazioni client pubbliche che non sono in grado di garantire la riservatezza delle credenziali.

Codice del dispositivo

Il flusso di codice del dispositivo OAuth 2.0 consente agli utenti di accedere a dispositivi vincolati di input, ad esempio tv intelligenti, dispositivi IoT 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 all'utente 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. Esempi di tali applicazioni includono quelli in esecuzione nei dispositivi IoT e negli strumenti dell'interfaccia della riga di comando.Examples of such applications include those running on IoT devices and command-line interface (CLI) tools.

Nel diagramma seguente:

  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 di procedere con una normale esperienza di autenticazione, incluse le richieste di consenso e l'autenticazione a più fattori, se necessario.
  2. Una volta completata correttamente l'autenticazione, l'app da riga di comando riceve i token necessari tramite un backchannel e li usa per eseguire le chiamate all'API Web necessarie.

Diagramma del flusso del codice del dispositivo.

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à:
    • Tenant: https://login.microsoftonline.com/{tenant}/, dove {tenant} è 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

Il flusso di concessione implicita è stato sostituito 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. Non è più consigliabile usare il flusso di concessione implicita. 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.0 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).

Diagramma del flusso di concessione implicito

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 ulteriori funzionalità per l'interazione con le piattaforme desktop e per dispositivi mobili native in cui vengono eseguite.

I token rilasciati tramite la modalità flusso implicita presentano una limitazione di lunghezza perché vengono restituiti al browser in base all'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.0 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. L'idea consiste nel propagare l'identità e le autorizzazioni dell'utente delegato tramite 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 .

Nel diagramma seguente:

  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, essa 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).

Diagramma del flusso on-behalf-of.

Nome utente/password (ROPC)

Avviso

Il flusso delle credenziali della password del proprietario della risorsa (ROPC) non è consigliato. ROPC richiede un elevato livello di attendibilità e esposizione delle credenziali. Ricorrere all'uso di 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.0 (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 come 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 seguente 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

Diagramma del flusso nome utente/password.

Per acquisire un token in modo invisibile all'utente nei computer windows aggiunti a un dominio, è consigliabile integrare autenticazione di Windows (IWA) 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 ASP.NET Core.
  • ROPC non è supportato nelle applicazioni piattaforma UWP (Universal Windows Platform) (UWP).
  • ROPC in Azure AD B2C è supportato solo per gli account locali.

Integrated autenticazione di Windows (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. Usando IWA, queste applicazioni acquisiscono automaticamente un token senza richiedere l'interazione dell'interfaccia utente da parte dell'utente.

Nel diagramma seguente l'applicazione:

  1. Acquisisce un token usando autenticazione di Windows integrato
  2. Usa il token per effettuare richieste della risorsa

Diagramma delle autenticazione di Windows integrate.

Vincoli per IWA

Compatibilità

L'autenticazione di Windows integrata è abilitata per le app .NET desktop, .NET e UWP (Universal Platform).

IWA supporta solo gli utenti federati ad AD FS, ovvero gli 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.

Autenticazione a più fattori (MFA)

L'autenticazione non interattiva (invisibile all'utente) di IWA può non riuscire se l'autenticazione a più fattori è abilitata nel tenant di Microsoft Entra e viene generata una richiesta di autenticazione a più fattori 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 Microsoft Entra specificato. 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.

I valori dell'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 avere precedentemente acconsentito all'uso dell'applicazione.

    OPPURE

  • L'amministratore tenant deve avere precedentemente acconsentito all'uso dell'applicazione da parte di tutti gli utenti del tenant.

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 Consenso utente.
  • È stato fornito un modo per consentire all'amministratore tenant di fornire il consenso per l'applicazione; vedere Amministrazione istrator consent.

Per altre informazioni sul consenso, vedere Autorizzazioni e consenso.

Passaggio successivo

Informazioni sull'acquisizione e la memorizzazione nella cache dei token usati in questi flussi:

Acquisire e memorizzare nella cache i token utilizzando Microsoft Authentication Library (MSAL)