Accesso all'applicazione a pagina singola usando il flusso implicito OAuth 2.0 in Azure Active Directory B2C

Importante

A partire dal 1° maggio 2025, Azure AD B2C non sarà più disponibile per l'acquisto per i nuovi clienti. Altre informazioni sono disponibili nelle domande frequenti.

Molte applicazioni moderne dispongono di un front-end per app a pagina singola scritto principalmente in JavaScript. Spesso l'app viene scritta usando un framework come React, Angular o Vue.js. Le applicazioni a pagina singola e altre app JavaScript eseguite principalmente in un browser presentano alcune sfide aggiuntive per l'autenticazione:

• Le caratteristiche di sicurezza di queste app sono diverse dalle tradizionali applicazioni Web basate su server.

• Molti server di autorizzazione e provider di identità non supportano le richieste CORS (Cross-Origin Resource Sharing).

• I reindirizzamenti a pagina intera del browser dall'app possono essere invasivi per l'esperienza dell'utente.

Avvertimento

Microsoft consiglia di non usare il flusso di concessione implicita. Il modo consigliato per supportare le applicazioni a livello di servizio è il flusso del codice di autorizzazione OAuth 2.0 (con PKCE). Alcune configurazioni di questo flusso richiedono un livello di attendibilità molto elevato nell'applicazione e comportano rischi che non sono presenti in altri flussi. Si consiglia di usare questo flusso solo quando non è possibile usare altri flussi più sicuri. Per altre informazioni, vedere i problemi di sicurezza relativi al flusso di concessione implicita.

Alcuni framework, ad esempio MSAL.js 1.x, supportano solo il flusso di concessione implicita. In questi casi, Azure Active Directory B2C (Azure AD B2C) supporta il flusso di concessione implicita dell'autorizzazione OAuth 2.0. Il flusso è descritto nella sezione 4.2 della specifica OAuth 2.0. Nel flusso implicito, l'app riceve i token direttamente dall'endpoint di autorizzazione di Azure AD B2C, senza alcuno scambio da server a server. Tutta la logica di autenticazione e la gestione delle sessioni vengono eseguite interamente nel client JavaScript con un reindirizzamento della pagina o una finestra pop-up.

Azure AD B2C estende il flusso implicito OAuth 2.0 standard a qualcosa di più della semplice autenticazione e autorizzazione. Azure AD B2C introduce il parametro policy. Con il parametro policy, è possibile utilizzare OAuth 2.0 per aggiungere criteri all'app, ad esempio i flussi utente di registrazione, accesso e gestione dei profili. Nelle richieste HTTP di esempio in questo articolo viene usato {tenant}.onmicrosoft.com per l'illustrazione. Sostituisci {tenant} con il nome del tuo inquilino , se ne hai uno. Inoltre, è necessario aver creato un flusso utente.

La figura seguente viene usata per illustrare il flusso di accesso implicito. Ogni passaggio è descritto in dettaglio più avanti nell'articolo.

Inviare richieste di autenticazione

Quando l'applicazione Web deve autenticare l'utente ed eseguire un flusso utente, indirizza l'utente all'endpoint di /authorize Azure AD B2C. L'utente esegue un'azione a seconda del flusso utente.

In questa richiesta, il client indica le autorizzazioni che deve acquisire dall'utente nel scope parametro e il flusso utente da eseguire. Per avere un'idea del funzionamento della richiesta, prova a incollare la richiesta in un browser ed eseguirla. Sostituire:

• {tenant} con il nome del tenant di Azure AD B2C.

• 00001111-aaaa-2222-bbbb-3333cccc4444 con l'ID app dell'applicazione che hai registrato nel tuo tenant.

• {policy} con il nome di una policy che hai creato nel tuo tenant, ad esempio b2c_1_sign_in.

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=id_token+token
&redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
&response_mode=fragment
&scope=openid%20offline_access
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345

I parametri nella richiesta HTTP GET sono illustrati nella tabella seguente.

Parametro	Obbligatorio	Descrizione
{tenant}	Sì	Nome del tenant di Azure AD B2C
{politica}	Sì	Nome del flusso utente che si desidera eseguire. Specificare il nome di un flusso utente creato nel tenant di Azure AD B2C. Per esempio: b2c_1_sign_in, b2c_1_sign_up, o b2c_1_edit_profile.
ID cliente	Sì	L'ID dell'applicazione assegnato dal portale di Azure alla tua applicazione.
tipo_di_risposta	Sì	Deve includere id_token per l'accesso a OpenID Connect. Può anche includere il tipo di risposta token. Se si utilizza token, l'app può ricevere immediatamente un token di accesso dall'endpoint di autorizzazione, senza effettuare una seconda richiesta all'endpoint di autorizzazione. Se si utilizza il tipo di token risposta, il scope parametro deve contenere un ambito che indichi la risorsa per la quale emettere il token.
uri_di_reindirizzamento	NO	URI di reindirizzamento dell'app dove le risposte di autenticazione possono essere inviate e ricevute dall'app. Deve corrispondere esattamente a uno degli URI di reindirizzamento aggiunti a un'applicazione registrata nel portale, ad eccezione del fatto che deve essere codificato in URL.
modalità_di_risposta	NO	Specifica il metodo da usare per inviare nuovamente il token risultante all'app. Per i flussi impliciti, utilizzare fragment.
scopo	Sì	Elenco di ambiti separati da spazi. Un singolo valore di ambito indica all'ID Microsoft Entra entrambe le autorizzazioni richieste. L'ambito openid indica un'autorizzazione per l'accesso dell'utente e per ottenere i dati relativi all'utente sotto forma di token ID. L'ambito offline_access è facoltativo per le app Web. Indica che l'app necessita di un token di aggiornamento per l'accesso di lunga durata alle risorse.
stato	NO	Valore incluso nella richiesta che viene restituito anche nella risposta del token. Può essere una stringa di qualsiasi contenuto che si desidera utilizzare. Di solito, viene utilizzato un valore univoco generato in modo casuale per prevenire attacchi di falsificazione delle richieste tra siti. Lo stato viene usato anche per codificare le informazioni sullo stato dell'utente nell'app prima che si verificasse la richiesta di autenticazione, ad esempio la pagina in cui si trovava l'utente o il flusso utente in esecuzione.
nonce	Sì	Valore incluso nella richiesta (generata dall'app) che viene incluso nel token ID risultante come dichiarazione. L'app può quindi verificare questo valore per l'attenuazione degli attacchi di riproduzione del token. In genere, il valore è una stringa univoca casuale che può essere utilizzata per identificare l'origine della richiesta.
richiesta	NO	Il tipo di interazione dell'utente richiesta. Attualmente, l'unico valore valido è login. Questo parametro impone all'utente di immettere le proprie credenziali per tale richiesta. Il singolo Sign-On non ha effetto.

Questa è la parte interattiva del flusso. All'utente viene chiesto di completare il flusso di lavoro della politica. L'utente potrebbe dover immettere il nome utente e la password, accedere con un'identità di social networking, registrarsi per un account locale o qualsiasi altro numero di passaggi. Le azioni utente dipendono dalla modalità di definizione del flusso utente.

Dopo che l'utente ha completato il flusso utente, Azure AD B2C restituisce una risposta all'app tramite il codice redirect_uri. Usa il metodo specificato nel response_mode parametro . La risposta è esattamente la stessa per ogni scenario di azione dell'utente, indipendentemente dal flusso utente eseguito.

Risposta riuscita

Una risposta riuscita che utilizza response_mode=fragment e response_type=id_token+token ha un aspetto simile al seguente, con interruzioni di riga per la leggibilità:

GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&token_type=Bearer
&expires_in=3599
&scope="00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier

Parametro	Descrizione
token di accesso	Token di accesso richiesto dall'app ad Azure AD B2C.
tipo di token	Valore del tipo di token. L'unico tipo supportato da Azure AD B2C è Bearer.
scade_in	Periodo di tempo in cui il token di accesso è valido (in secondi).
scopo	Ambiti per cui il token è valido. È anche possibile usare gli ambiti per memorizzare nella cache i token per usarli in un secondo momento.
id_token (token di identificazione)	Token ID richiesto dall'app. È possibile usare il token ID per verificare l'identità dell'utente e avviare una sessione con l'utente. Per altre informazioni sui token ID e sul relativo contenuto, vedere le informazioni di riferimento sui token di Azure AD B2C.
stato	Se nella richiesta è incluso un parametro state, lo stesso valore deve essere visualizzato nella risposta. L'app deve verificare che i state valori nella richiesta e nella risposta siano identici.

Risposta di errore

Le risposte di errore possono anche essere inviate all'URI di reindirizzamento in modo che l'app possa gestirle in modo appropriato:

GET https://aadb2cplayground.azurewebsites.net/#
error=access_denied
&error_description=the+user+canceled+the+authentication
&state=arbitrary_data_you_can_receive_in_the_response

Parametro	Descrizione
Errore	Codice utilizzato per classificare i tipi di errori che si verificano.
descrizione_errore	Messaggio di errore specifico che consente di identificare la causa principale di un errore di autenticazione.
stato	Se nella richiesta è incluso un parametro state, lo stesso valore deve essere visualizzato nella risposta. L'app deve verificare che i state valori nella richiesta e nella risposta siano identici.

Convalidare il token ID

La ricezione di un token ID non è sufficiente per autenticare l'utente. Convalidare la firma del token ID e verificare le attestazioni nel token in base ai requisiti dell'app. Azure AD B2C usa token WEB JSON (JWT) e la crittografia a chiave pubblica per firmare i token e verificare che siano validi.

Sono disponibili molte librerie open source per la convalida dei token JWT, a seconda del linguaggio che si preferisce utilizzare. Prendere in considerazione l'esplorazione delle librerie open source disponibili anziché implementare una logica di convalida personalizzata. È possibile utilizzare le informazioni contenute in questo articolo per apprendere come utilizzare correttamente tali librerie.

Azure AD B2C ha un endpoint di metadati OpenID Connect. Un'app può usare l'endpoint per recuperare informazioni su Azure AD B2C in fase di esecuzione. Queste informazioni includono endpoint, contenuto del token e chiavi di firma del token. È disponibile un documento di metadati JSON per ogni flusso utente nel tenant di Azure AD B2C. Ad esempio, il documento di metadati per un flusso utente denominato b2c_1_sign_in in un fabrikamb2c.onmicrosoft.com tenant si trova in:

https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/v2.0/.well-known/openid-configuration

Una delle proprietà di questo documento di configurazione è .jwks_uri Il valore per lo stesso flusso utente sarebbe:

https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/discovery/v2.0/keys

Per determinare quale flusso utente è stato utilizzato per firmare un token ID (e da dove recuperare i metadati), è possibile utilizzare una delle opzioni seguenti:

• Il nome del flusso utente è incluso nell'attestazione acr in id_token. Per informazioni su come analizzare le attestazioni da un token ID, vedere le informazioni di riferimento sui token di Azure AD B2C.

• Codificare il flusso utente nel valore del state parametro quando si invia la richiesta. Quindi, decodificare il state parametro per determinare quale flusso utente è stato utilizzato.

Dopo aver acquisito il documento di metadati dall'endpoint di metadati OpenID Connect, è possibile utilizzare le chiavi pubbliche RSA-256 (che si trovano in questo endpoint) per convalidare la firma del token ID. Potrebbero essere presenti più chiavi elencate in questo endpoint in un dato momento, ognuna identificata da un kid. L'intestazione di id_token contiene anche un'attestazione kid . Indica quale di queste chiavi è stata utilizzata per firmare il token ID. Per altre informazioni, incluse le informazioni sulla convalida dei token, vedere le informazioni di riferimento sui token di Azure AD B2C.

Dopo aver convalidato la firma del token ID, è necessario verificare diverse attestazioni. Per esempio:

• Convalidare l'attestazione nonce per impedire attacchi di riproduzione del token. Il valore deve essere quello specificato nella richiesta di accesso.

• Convalida l'attestazione aud per assicurarti che il token ID sia stato emesso per la tua app. Il valore deve essere l'ID applicazione dell'app.

• Convalida le rivendicazioni iat e exp per assicurarsi che il token ID non sia scaduto.

Diverse altre convalide da eseguire sono descritte in dettaglio nelle specifiche di base di OpenID Connect. Potrebbe anche essere necessario convalidare attestazioni aggiuntive, a seconda dello scenario. Alcune convalide comuni includono:

• Assicurarsi che l'utente o l'organizzazione si sia registrato per l'app.

• Assicurarsi che l'utente disponga dell'autorizzazione e dei privilegi appropriati.

• Garantire che si sia verificato un certo livello di autenticazione, ad esempio utilizzando l'autenticazione a più fattori di Microsoft Entra.

Per altre informazioni sulle attestazioni in un token ID, vedere le informazioni di riferimento sul token Azure AD B2C.

Dopo aver convalidato il token ID, è possibile avviare una sessione con l'utente. Nell'app usare le attestazioni nel token ID per ottenere informazioni sull'utente. Queste informazioni possono essere utilizzate per la visualizzazione, la registrazione, l'autorizzazione e così via.

Ottieni token di accesso

Se l'unica cosa che le tue app Web devono fare è eseguire i flussi utente, puoi saltare le sezioni successive. Le informazioni nelle sezioni seguenti sono applicabili solo alle app Web che devono effettuare chiamate autenticate a un'API Web protetta da Azure AD B2C stesso.

Ora che hai eseguito l'accesso dell'utente alla tua SPA, puoi ottenere i token di accesso per chiamare le API web protette dalla protezione di Microsoft Entra ID. Anche se hai già ricevuto un token usando il token tipo di risposta, puoi usare questo metodo per acquisire token per risorse aggiuntive senza reindirizzare l'utente a eseguire nuovamente l'accesso.

In un tipico flusso di app Web, è necessario effettuare una richiesta all'endpoint /token . Tuttavia, l'endpoint non supporta le richieste CORS, quindi l'esecuzione di chiamate AJAX per ottenere un token di aggiornamento non è un'opzione. È invece possibile usare il flusso implicito in un elemento iframe HTML nascosto per ottenere nuovi token per altre API Web. Di seguito è riportato un esempio, con interruzioni di riga per la leggibilità:

https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=token
&redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
&scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read
&response_mode=fragment
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
&prompt=none

Parametro	Obbligatorio?	Descrizione
{tenant}	Obbligatorio	Nome del tenant di Azure AD B2C
{politica}	Obbligatorio	Il flusso utente da eseguire. Specificare il nome di un flusso utente creato nel tenant di Azure AD B2C. Per esempio: b2c_1_sign_in, b2c_1_sign_up, o b2c_1_edit_profile.
ID cliente	Obbligatorio	ID applicazione assegnato all'app nel portale di Azure.
tipo_di_risposta	Obbligatorio	Deve includere id_token per l'accesso a OpenID Connect. Potrebbe anche includere il tipo di risposta token. Se si usa token questa opzione, l'app può ricevere immediatamente un token di accesso dall'endpoint di autorizzazione, senza effettuare una seconda richiesta all'endpoint di autorizzazione. Se si utilizza il tipo di token risposta, il scope parametro deve contenere un ambito che indichi la risorsa per la quale emettere il token.
uri_di_reindirizzamento	Consigliato	URI di reindirizzamento dell'app dove le risposte di autenticazione possono essere inviate e ricevute dall'app. Deve corrispondere esattamente a uno degli URI di reindirizzamento registrati nel portale, ad eccezione del fatto che deve essere codificato come URL.
scopo	Obbligatorio	Elenco di ambiti separati da spazi. Per ottenere i token, includere tutti gli ambiti necessari per la risorsa prevista.
modalità_di_risposta	Consigliato	Specifica il metodo usato per inviare nuovamente il token risultante all'app. Per il flusso implicito, utilizzare fragment. Due altre modalità possono essere specificate, query e form_post, ma non funzionano nel flusso implicito.
stato	Consigliato	Valore incluso nella richiesta restituita nella risposta del token. Può essere una stringa di qualsiasi contenuto che si desidera utilizzare. Di solito, viene utilizzato un valore univoco generato in modo casuale per prevenire attacchi di falsificazione delle richieste tra siti. Anche lo stato viene usato per codificare le informazioni sullo stato dell'utente nell'app prima del verificarsi della richiesta di autenticazione, Ad esempio, la pagina o la visualizzazione in cui si trovava l'utente.
nonce	Obbligatorio	Un valore incluso nella richiesta, generato dall'app incluso nel token ID risultante come attestazione. L'app può quindi verificare questo valore per l'attenuazione degli attacchi di riproduzione del token. In genere, il valore è una stringa univoca casuale che identifica l'origine della richiesta.
richiesta	Obbligatorio	Per aggiornare e ottenere i token in un iframe nascosto, utilizzare prompt=none per assicurarsi che l'iframe non si blocchi nella pagina di accesso e ritorni immediatamente.
suggerimento di login	Obbligatorio	Per aggiornare e ottenere i token in un iframe nascosto, includere il nome utente dell'utente in questo suggerimento per distinguere tra più sessioni che l'utente potrebbe avere in un determinato momento. È possibile estrarre il nome utente da un accesso precedente usando l'attestazione preferred_username (l'ambito profile è necessario per ricevere l'attestazione preferred_username ).
suggerimento_dominio	Obbligatorio	Può essere consumers o organizations. Per aggiornare e ottenere token in un iframe nascosto, includere il valore domain_hint nella richiesta. Estrarre l'attestazione tid dal token ID di un accesso precedente per determinare il valore da usare (l'ambito profile è necessario per ricevere l'attestazione tid ). Se il valore dell'attestazione tid è 9188040d-6c67-4c5b-b112-36a304b66dad, utilizzare domain_hint=consumers. In caso contrario, usare domain_hint=organizations.

Impostando il prompt=none parametro, questa richiesta ha esito positivo o negativo immediatamente e viene restituita all'applicazione. Una risposta corretta viene inviata all'app tramite l'URI di reindirizzamento, usando il response_mode metodo specificato nel parametro.

Risposta riuscita

Una risposta riuscita utilizzando response_mode=fragment è simile al seguente esempio:

GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier
&token_type=Bearer
&expires_in=3599
&scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read

Parametro	Descrizione
token di accesso	Il token richiesto dall'app.
tipo di token	Il tipo di token sarà sempre Bearer.
stato	Se nella richiesta è incluso un parametro state, lo stesso valore deve essere visualizzato nella risposta. L'app deve verificare che i state valori nella richiesta e nella risposta siano identici.
scade_in	Tempo di validità del token di accesso (in secondi).
scopo	Ambiti per i quali è valido il token di accesso.

Risposta di errore

Le risposte di errore possono anche essere inviate all'URI di reindirizzamento in modo che l'app possa gestirle in modo appropriato. Per prompt=none, un errore previsto è simile al seguente esempio:

GET https://aadb2cplayground.azurewebsites.net/#
error=user_authentication_required
&error_description=the+request+could+not+be+completed+silently

Parametro	Descrizione
Errore	Stringa di codice di errore che può essere usata per classificare i tipi di errori che si verificano. È anche possibile usare la stringa per reagire agli errori.
descrizione_errore	Messaggio di errore specifico che consente di identificare la causa principale di un errore di autenticazione.

Se si riceve questo errore nella richiesta iframe, l'utente deve accedere di nuovo in modo interattivo per recuperare un nuovo token.

Token di aggiornamento

I token ID e i token di accesso scadono entrambi dopo un breve periodo di tempo. L'app deve essere pronta ad aggiornare periodicamente questi token. I flussi impliciti non consentono di ottenere un token di aggiornamento per motivi di sicurezza. Per aggiornare entrambi i tipi di token, utilizzare il flusso implicito in un elemento iframe HTML nascosto. Nella richiesta di autorizzazione includere il prompt=none parametro. Per ricevere un nuovo valore id_token, assicurarsi di utilizzare response_type=id_token e scope=openid, e un parametro nonce.

Inviare una richiesta di disconnessione

Quando si vuole disconnettere l'utente dall'app, reindirizzare l'utente all'endpoint di disconnessione di Azure AD B2C. È quindi possibile cancellare la sessione dell'utente nell'app. Se non si reindirizza l'utente, potrebbe essere possibile ripetere l'autenticazione all'app senza immettere di nuovo le credenziali perché ha una sessione single Sign-On valida con Azure AD B2C.

È sufficiente reindirizzare l'utente a end_session_endpoint ciò che è elencato nello stesso documento di metadati OpenID Connect descritto in Convalidare il token ID. Per esempio:

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F

Parametro	Obbligatorio	Descrizione
{tenant}	Sì	Nome del tenant di Azure AD B2C.
{politica}	Sì	Flusso utente che si desidera utilizzare per disconnettere l'utente dall'applicazione. Deve trattarsi dello stesso flusso utente usato dall'app per l'accesso dell'utente.
URI di reindirizzamento post-logout	NO	URL a cui l'utente deve essere reindirizzato dopo la disconnessione riuscita. Se non è incluso, Azure AD B2C mostra all'utente un messaggio generico.
stato	NO	Se nella richiesta è incluso un parametro state, lo stesso valore deve essere visualizzato nella risposta. L'applicazione deve verificare che i state valori nella richiesta e nella risposta siano identici.

Annotazioni

Indirizzando l'utente allo end_session_endpoint stato single Sign-On dell'utente con Azure AD B2C. Tuttavia, non disconnette l'utente dalla sessione del provider di identità social dell'utente. Se l'utente seleziona lo stesso provider di identità durante un accesso successivo, l'utente viene autenticato di nuovo, senza immettere le credenziali. Se un utente vuole disconnettersi dall'applicazione Azure AD B2C, non significa necessariamente che voglia disconnettersi completamente dal proprio account Facebook, ad esempio. Tuttavia, per gli account locali, la sessione dell'utente verrà terminata correttamente.

Passaggi successivi

Vedere l'esempio di codice: Accesso con Azure AD B2C in un'applicazione SPA in JavaScript.