Condividi tramite

Supporto del flusso di autenticazione in MSAL

  • Articolo

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

Flusso di autenticazione Abilita Tipi di applicazione supportati
Codice di autorizzazione Accesso utente e accesso alle API Web per conto dell'utente. Desktop
Dispositivi mobili
SPA (App a pagina singola) (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, dispositivi mobili
Concessione implicita Accesso utente e accesso alle API Web per conto dell'utente. Non usare questo flusso: usare invece il codice di autorizzazione con PKCE. * App a pagina singola
* Web
OBO (On-Behalf-Of) 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. Web API
Nome utente/password (ROPC) Consente a un'applicazione di eseguire l'accesso dell'utente gestendone direttamente la password. Non usare questo flusso. Desktop, dispositivi mobili
Autenticazione integrata di Windows (IWA) Consente alle applicazioni nei computer aggiunti a dominio o Microsoft Entra di acquisire un token in modo invisibile all'utente (senza alcuna interazione dell'interfaccia utente dell'utente). Desktop, dispositivi mobili

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 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 Funzionamento del codice di autorizzazione
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) nome utente, 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 Funzionamento del codice di autorizzazione
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 interattiva e non interattiva.

  • Interattiva: il server di autorizzazione può richiedere all'utente di inserire i dati. Ad esempio, per accedere, eseguire l'autenticazione a più fattori (MFA) o concedere il consenso a più autorizzazioni di accesso alle risorse.
  • Non interattiva: all'utente non può essere richiesto di inserire dati. 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 cercare di acquisire un token in modo invisibile e passare al metodo interattivo solo se il tentativo non interattivo ha esito negativo. Per ulteriori informazioni, consultare Acquisire e memorizzare nella cache i token tramite MSAL (Microsoft Authentication Library).

Codice di autorizzazione

La concessione del codice di autorizzazione OAuth 2.0 può essere usata dalle App Web, dalle SPA (app a pagina singola) 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 ottenere un token di accesso per chiamare le API Web.

Nel diagramma seguente, l'applicazione:

  1. Richiede un codice di autorizzazione, che viene 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 PKCE (chiave di prova per scambio di codice) quando viene usato il flusso di concessione del codice di autorizzazione. PKCE è supportata da MSAL.

  • La specifica OAuth 2.0 richiede di usare un codice di autorizzazione per riscattare un token di accesso solo una volta.

    Se si cerca di acquisire il token di accesso più volte con lo stesso codice di autorizzazione, Microsoft Identity Platform restituisce un errore simile al seguente. Alcune librerie e framework richiedono il codice di autorizzazione in modo automatico e, in questi casi, anche la richiesta manuale di un codice può generare 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 delle credenziali client OAuth 2.0 consente di accedere a risorse ospitate nel 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 il segreto dell'applicazione o le credenziali della password
  2. Usa il token per effettuare richieste della risorsa

Diagramma del client riservato con password.

Certificati

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 un'app Microsoft Entra ID
  • Passato durante la creazione dell'oggetto riservato dell'applicazione client 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 come smart TV, 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 di codice del dispositivo consente all'utente di usare un altro dispositivo, come un computer o un telefono cellulare, per accedere in modo interattivo.

Utilizzando il flusso di codice del dispositivo, l'applicazione ottiene i token attraverso un processo a due fasi progettato per questi dispositivi e sistemi operativi. Esempi di tali applicazioni sono quelle in esecuzione su dispositivi IoT e CLI ( strumenti di interfaccia della riga di comando).

Nel diagramma seguente:

  1. Quando è richiesta l'autenticazione dell'utente, l'applicazione fornisce un codice e chiede all'utente di usare un altro dispositivo, come uno smartphone connesso a Internet, per accedere a un URL (ad esempio, https://microsoft.com/devicelogin). All'utente viene quindi richiesto di inserire il codice e di procedere con la normale esperienza di autenticazione, comprese le richieste di consenso e di 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 di codice del dispositivo.

Vincoli per il codice del dispositivo

  • Il flusso di codice del dispositivo è disponibile solo per le applicazioni client pubbliche.
  • Quando viene inizializzata 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 codice di autorizzazione con PKCE come flusso di concessione del token preferito e più sicuro per le applicazioni a pagina singola (SPA) lato client

Avviso

Non è più consigliato l'uso del flusso di concessione implicita. Se si sta creando una SPA, usare invece il flusso del codice di autorizzazione con PKCE.

Le app Web a pagina singola realizzate in JavaScript (compresi framework come Angular, Vue.js o React.js) vengono scaricate dal server e il relativo codice viene eseguito direttamente nel browser. Poiché il relativo codice lato client viene eseguito nel browser e non su un server Web, presentano caratteristiche di sicurezza diverse rispetto alle applicazioni Web tradizionali lato server. Prima della disponibilità di PKCE (chiave di prova per scambio di codice) per il flusso del codice di autorizzazione, il flusso di concessione implicita era usato dalle SPA per migliorare la reattività e l'efficienza nell'ottenimento dei token di accesso.

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

Diagramma del flusso di concessione implicito

Vincoli per la concessione implicita

Il flusso di concessione implicita non include gli scenari applicativi che sfruttano framework JavaScript multipiattaforma come Electron o React Native. I framework multipiattaforma come questi richiedono ulteriori funzionalità per l'interazione con le piattaforme native desktop e mobili su cui vengono eseguiti.

I token emessi tramite la modalità di flusso implicito presentano una limitazione di lunghezza perché vengono restituiti al browser tramite URL (dove response_mode è query o fragment). Alcuni browser limitano la lunghezza dell'URL nella barra degli indirizzi e hanno esito negativo se l'URL è troppo lungo. Pertanto, questi token di flusso implicito non contengono attestazioni groups o wids.

OBO (On-Behalf-Of)

Il 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 API Web. L'idea consiste nel propagare l'identità e le autorizzazioni dell'utente delegato tramite la catena di richieste. Per poter effettuare richieste autenticate al servizio downstream, il servizio di livello intermedio deve ottenere 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)

La concessione delle credenziali password del proprietario della risorsa (ROPC) OAuth 2.0consente a un'applicazione di far accedere l'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.

Avviso

Il flusso di credenziali password del proprietario della risorsa (ROPC) NON è consigliato. ROPC richiede un alto livello di attendibilità e di 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?.

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 su computer Windows collegati a un dominio, è consigliata l'autenticazione integrata di Windows (IWA) ainché 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, consultarsi con l'amministratore tenant: l'MFA è una funzione comunemente usata.
  • L'accesso condizionale non è supportato.
  • ROPC funziona solo per gli account aziendali e dell'istituto di istruzione.
  • Gli account Microsoft personali (MSA) 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).
  • ROPC in Azure AD B2C è supportato solo per gli account locali.

Autenticazione integrata di Windows (IWA)

MSAL supporta l'autenticazione integrata di Windows (IWA) per le applicazioni desktop e mobili eseguite su computer Windows aggiunti al dominio o aggiunti a Microsoft Entra. Usando IWA, queste applicazioni acquisiscono un token in modo invisibile senza richiedere l'interazione dell'interfaccia utente.

Nel diagramma seguente, l'applicazione:

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

Diagramma dell'autenticazione integrata di Windows.

Vincoli per l'autenticazione integrata di Windows

Compatibilità

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

L'autenticazione integrata di Windows (IWA) supporta solo gli utenti federati 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 per Active Directory (utenti gestiti) non possono usare questo flusso di autenticazione.

Autenticazione a più fattori (MFA)

L'autenticazione non interattiva (invisibile) dell'autenticazione integrata di Windows (IWA) può non riuscire se l'MFA è abilitata nel tenant di Microsoft Entra e se un'autenticazione MFA viene effettuata da Microsoft Entra ID. Qualora l'autenticazione integrata di Windows (IWA) non dovesse funzionare, è necessario ricorrere 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 è generalmente richiesta quando un utente accede da un paese/regione diversa, quando si connette a una rete aziendale senza utilizzare una VPN e talvolta quando è connesso tramite una VPN. Considerando che la configurazione dell'MFA e la frequenza delle sfide possono non rientrare sotto il controllo dello sviluppatore, l'applicazione deve essere in grado di gestire in modo efficiente eventuali errori nell'acquisizione automatica del token tramite l'autenticazione integrata di Windows (IWA).

Restrizioni URI delle autorità

L'autorità passata al momento della creazione dell'applicazione client pubblica deve essere una delle seguenti:

  • https://login.microsoftonline.com/{tenant}/: questa autorità indica un'applicazione a tenant singolo il cui pubblico di accesso è limitato agli utenti del tenant Microsoft Entra specificato. Il valore {tenant} può essere l'ID tenant in forma GUID o il nome di dominio associato al tenant.
  • https://login.microsoftonline.com/organizations/: questa autorità indica un'applicazione multi-tenant il cui pubblico di accesso è costituito da utenti di qualsiasi tenant di Microsoft Entra.

I valori delle autorità NON devono contenere /common o /consumers poiché gli account Microsoft personali (MSA) non sono supportati dall'autenticazione integrata di Windows (IWA).

Requisiti di consenso

Poiché l'autenticazione integrata di Windows (IWA) è un flusso invisibile:

  • 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 uno dei due requisiti, una di queste operazioni deve essere stata completata:

  • Lo sviluppatore dell'applicazione ha selezionato Concedi nel portale di Azure.
  • Un amministratore tenant ha selezionato Concedi/revoca consenso amministratore per {dominio tenant} nella scheda Autorizzazioni API della registrazione app nel portale di Azure; consultare Aggiungere autorizzazioni per l'accesso alle API Web.
  • È stato fornito un modo per consentire agli utenti di dare il consenso all'applicazione; consultare Consenso utente.
  • È stato fornito un modo per consentire all'amministratore tenant di dare il consenso all'applicazione; vedere Consenso amministratore.

Per ulteriori informazioni sul consenso, consultare Autorizzazioni e consenso.

Passaggio successivo

Ulteriori 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)