Condividi tramite

Flusso del codice di autorizzazione 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.

È possibile usare la concessione del codice di autorizzazione OAuth 2.0 nelle app installate in un dispositivo per ottenere l'accesso alle risorse protette, ad esempio le API Web. Usando l'implementazione di Azure Active Directory B2C (Azure AD B2C) di OAuth 2.0, è possibile aggiungere attività di iscrizione, accesso e altre attività di gestione delle identità alle app desktop, per dispositivi mobili e a pagina singola. In questo articolo viene descritto come inviare e ricevere messaggi HTTP senza usare librerie open source. Questo articolo è indipendente dal linguaggio. Quando possibile, è consigliabile usare le librerie di autenticazione Microsoft supportate (MSAL). Esaminare le app di esempio che usano MSAL.

Il flusso del codice di autorizzazione di OAuth 2.0 è descritto nella sezione 4.1 della specifica di OAuth 2.0. È possibile usarlo per l'autenticazione e l'autorizzazione nella maggior parte dei tipi di applicazioni, incluse applicazioni Web, applicazioni a pagina singola e applicazioni installate in modo nativo. È possibile usare il flusso del codice di autorizzazione OAuth 2.0 per acquisire in modo sicuro i token di accesso e i token di aggiornamento per le applicazioni, che possono essere usati per accedere alle risorse protette da un server di autorizzazione. Il token di aggiornamento consente al client di acquisire nuovi token di accesso (e di aggiornamento) dopo la scadenza del token di accesso, in genere dopo un'ora.

Questo articolo è incentrato sul flusso del codice di autorizzazione OAuth 2.0 dei client pubblici . Un client pubblico è qualsiasi applicazione client che non può essere considerata attendibile per mantenere in modo sicuro l'integrità di una password segreta. Sono incluse applicazioni a pagina singola, app per dispositivi mobili, applicazioni desktop e essenzialmente qualsiasi applicazione che non viene eseguita in un server.

Annotazioni

Per aggiungere la gestione delle identità a un'app Web usando Azure AD B2C, usare OpenID Connect anziché OAuth 2.0.

Azure AD B2C estende i flussi standard di OAuth 2.0 per fare più che semplici operazioni di autenticazione e autorizzazione. Introduce il flusso utente. Con i flussi utente, è possibile usare OAuth 2.0 per aggiungere esperienze utente all'applicazione, ad esempio la gestione di iscrizione, accesso e profilo. I provider di identità che usano il protocollo OAuth 2.0 includono Amazon, Microsoft Entra ID, Facebook, GitHub, Google e LinkedIn.

Per provare le richieste HTTP in questo articolo:

  1. Sostituire {tenant} con il nome del tenant di Azure AD B2C.
  2. Sostituire 00001111-aaaa-2222-bbbb-3333cccc4444 con l'ID app di un'applicazione registrata in precedenza nel tenant di Azure AD B2C.
  3. Sostituire {policy} con il nome di una politica creata nel tenant, ad esempio b2c_1_sign_in.

Configurazione dell'URI di reindirizzamento necessaria per le app a pagina singola

Il flusso del codice di autorizzazione per le applicazioni a pagina singola richiede un'installazione aggiuntiva. Segui le istruzioni per creare la tua applicazione a pagina singola e contrassegna correttamente l'URI di reindirizzamento come abilitato per il CORS. Per aggiornare un URI di reindirizzamento esistente per abilitare CORS, è possibile fare clic sulla richiesta di migrazione nella sezione "Web" della scheda Autenticazione della registrazione dell'app. In alternativa, è possibile aprire l'editor manifesto registrazioni app e impostare il campo per l'URI type di reindirizzamento su spa nella replyUrlsWithType sezione .

Il spa tipo di reindirizzamento è retrocompatibile con il flusso implicito. Le app che usano attualmente il flusso implicito per ottenere i token possono passare al spa tipo di URI di reindirizzamento senza problemi e continuare a usare il flusso implicito.

1. Ottenere un codice di autorizzazione

Il flusso del codice di autorizzazione ha inizio con il client che indirizza l'utente all'endpoint /authorize. Questa è la parte interattiva del flusso, in cui l'utente esegue un'azione. In questa richiesta, il client indica nel scope parametro le autorizzazioni che deve acquisire dall'utente. Gli esempi seguenti (con interruzioni di riga per la leggibilità) illustrano come acquisire un codice di autorizzazione. Se si sta testando questa richiesta HTTP GET, usare il browser.

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code
&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob
&response_mode=query
&scope=00001111-aaaa-2222-bbbb-3333cccc4444%20offline_access%20https://{tenant-name}/{app-id-uri}/{scope}
&state=arbitrary_data_you_can_receive_in_the_response
&code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl
&code_challenge_method=S256
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 Tipo di risposta, che deve includere code per il flusso del codice di autorizzazione. È possibile ricevere un token ID se lo si include nel tipo di risposta, ad esempio code+id_token, e in questo caso, l'ambito deve includere openid.
uri_di_reindirizzamento Obbligatorio 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. 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 applicazioni Web. Indica che l'applicazione necessita di un token di aggiornamento per l'accesso esteso alle risorse. L'ID client indica che il token emesso è destinato all'uso da parte del client registrato di Azure AD B2C. https://{tenant-name}/{app-id-uri}/{scope} Indica un'autorizzazione per le risorse protette, ad esempio un'API Web. Per altre informazioni, vedere Richiedere un token di accesso.
modalità_di_risposta Consigliato Metodo da usare per inviare all'app il codice di autorizzazione risultante. Può essere query, form_post o fragment.
stato Consigliato Valore incluso nella richiesta che può essere una stringa di qualsiasi contenuto che si intende usare. Per evitare attacchi di richiesta intersito falsa, in genere viene usato un valore univoco generato casualmente. 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 in cui si trova l'utente o il flusso utente che era in esecuzione.
richiesta Opzionale Tipo di interazione dell'utente necessario. Attualmente, l'unico valore valido è login, che impone all'utente di immettere le proprie credenziali su tale richiesta. Il Single Sign-On non funzionerà.
sfida di codice consigliato / obbligatorio Usato per proteggere i grant di codice di autorizzazione tramite la chiave di prova per lo scambio di codice (PKCE). Obbligatorio se code_challenge_method è incluso. È necessario aggiungere logica nella tua applicazione per generare i code_verifier e code_challenge. code_challenge è un hash SHA256 con codifica URL Base64 dell'oggetto code_verifier. Il valore code_verifier viene memorizzato nell'applicazione per un utilizzo successivo, e code_challenge viene inviato insieme alla richiesta di autorizzazione. Per altre informazioni, vedere il PKCE RFC. Questa opzione è ora consigliata per tutti i tipi di applicazioni: app native, applicazioni a pagina singola (SPA), e client riservati, come le app Web.
code_challenge_method consigliato / obbligatorio Metodo usato per codificare code_verifier per il parametro code_challenge. DEVE essere S256, ma la specifica consente l'uso di plain se per qualche motivo il client non può supportare SHA256.

Se si esclude code_challenge_method, ma si include code_challengeancora , si presuppone che sia code_challenge testo non crittografato. Microsoft Identity Platform supporta sia plain che S256. Per altre informazioni, vedere il PKCE RFC. Questa operazione è necessaria per le app a pagina singola usando il flusso del codice di autorizzazione.
suggerimento di login NO Può essere usato per precompilare il campo del nome di accesso della pagina di accesso. Per ulteriori informazioni, vedere Prepopolare il nome di accesso.
suggerimento_dominio NO Fornisce un suggerimento ad Azure AD B2C sul provider di identità sociale da usare per l'accesso. Se viene incluso un valore valido, l'utente va direttamente alla pagina di accesso del fornitore di identità. Per altre informazioni, vedere Reindirizzare l'accesso a un provider di social networking.
Parametri personalizzati NO Parametri personalizzati che possono essere usati con criteri personalizzati. Ad esempio, l'URI del contenuto della pagina personalizzata dinamica o i resolver di attestazioni chiave-valore.

A questo punto, all'utente viene chiesto di completare il processo del flusso utente. Ciò potrebbe comportare l'immissione del nome utente e della password, l'accesso con un'identità di social networking, l'iscrizione alla directory 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, Microsoft Entra ID restituisce una risposta all'app con il valore usato per 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.

Una risposta con esito positivo che usa response_mode=query è simile alla seguente:

GET urn:ietf:wg:oauth:2.0:oob?
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...        // the authorization_code, truncated
&state=arbitrary_data_you_can_receive_in_the_response                // the value provided in the request
Parametro Descrizione
codice Codice di autorizzazione richiesto dall'app. L'app può usare il codice di autorizzazione per richiedere un token di accesso per una risorsa di destinazione. I codici di autorizzazione sono di breve durata. In genere scadono dopo circa 10 minuti.
stato Vedere la descrizione completa nella tabella nella sezione precedente. 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.

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

GET urn:ietf:wg:oauth:2.0:oob?
error=access_denied
&error_description=The+user+has+cancelled+entering+self-asserted+information
&state=arbitrary_data_you_can_receive_in_the_response
Parametro Descrizione
Errore Stringa di codice di errore che è possibile usare 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.
stato Vedere la descrizione completa nella tabella precedente. 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.

2. Ottenere un token di accesso

Dopo aver acquisito un codice di autorizzazione, puoi scambiare il code per un token per la risorsa desiderata inviando una richiesta POST all'endpoint /token. In Azure AD B2C è possibile richiedere token di accesso per altre API come di consueto specificando gli ambiti nella richiesta.

È anche possibile richiedere un token di accesso per l'API Web back-end dell'app per convenzione usando l'ID client dell'app come ambito richiesto (che comporterà un token di accesso con tale ID client come "destinatari"):

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1

Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=00001111-aaaa-2222-bbbb-3333cccc4444 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
&code_verifier=ThisIsntRandomButItNeedsToBe43CharactersLong
Parametro Obbligatorio? Descrizione
{tenant} Obbligatorio Nome del tenant di Azure AD B2C
{politica} Obbligatorio Flusso utente usato per acquisire il codice di autorizzazione. Non è possibile usare un flusso utente diverso in questa richiesta.
ID cliente Obbligatorio ID applicazione assegnato all'app nel portale di Azure.
segreto_cliente Sì, nelle applicazioni web Segreto dell'applicazione generato nel portale di Azure. I segreti client vengono usati in questo flusso per gli scenari di app Web, in cui il client può archiviare in modo sicuro un segreto client. Per gli scenari di app nativa (client pubblico), i segreti client non possono essere archiviati in modo sicuro e pertanto non vengono usati in questa chiamata. Se si usa un segreto client, modificarlo periodicamente.
tipo_di_concessione Obbligatorio Tipo di concessione. Per il flusso del codice di autorizzazione, il tipo di concessione deve essere authorization_code.
scopo Consigliato Elenco di ambiti separati da spazi. Un singolo valore di ambito indica ad Azure AD B2C entrambe le autorizzazioni richieste. L'uso dell'ID client come ambito indica che l'app necessita di un token di accesso che può essere usato per il proprio servizio o l'API Web, rappresentato dallo stesso ID client. L'ambito offline_access indica che l'app necessita di un token di aggiornamento per l'accesso di lunga durata alle risorse. È anche possibile usare l'ambito openid per richiedere un token ID da Azure AD B2C.
codice Obbligatorio Il codice di autorizzazione che hai acquisito dall'endpoint /authorize.
uri_di_reindirizzamento Obbligatorio URI di reindirizzamento dell'applicazione in cui è stato ricevuto il codice di autorizzazione.
verificatore_di_codice consigliato Lo stesso code_verifier usato per ottenere il codice di autorizzazione. Obbligatorio se è stato usato PKCE nella richiesta di concessione del codice di autorizzazione. Per altre informazioni, vedere il PKCE RFC.

Se si sta testando questa richiesta HTTP POST, è possibile usare qualsiasi client HTTP, ad esempio Microsoft PowerShell.

Una risposta con esito positivo del token è simile alla seguente:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
Parametro Descrizione
non prima di Ora in cui il token è considerato valido, in fase di validità.
tipo di token Valore del tipo di token. L'unico tipo supportato da Microsoft Entra ID è Bearer.
token di accesso Il token JSON Web (JWT) firmato che hai richiesto.
scopo Ambiti per cui il token è valido. È anche possibile usare gli ambiti per memorizzare nella cache i token per usarli in un secondo momento.
scade_in Periodo di tempo in cui il token è valido (in secondi).
token di aggiornamento Token di aggiornamento di OAuth 2.0. L'app può usare questo token per acquisire token aggiuntivi dopo la scadenza del token corrente. I token di aggiornamento sono di lunga durata. È possibile usarli per mantenere l'accesso alle risorse per lunghi periodi di tempo. Per ulteriori informazioni, vedere il riferimento ai token di Azure AD B2C.

Le risposte di errore hanno un aspetto simile al seguente:

{
    "error": "access_denied",
    "error_description": "The user revoked access to the app.",
}
Parametro Descrizione
Errore Stringa di codice di errore che è possibile usare 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.

3. Usare il token

Dopo aver acquisito correttamente un token di accesso, è possibile usare il token nelle richieste alle API Web back-end includendolo nell'intestazione Authorization :

GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

4. Aggiornare il token

I token di accesso e i token ID sono di breve durata. Dopo la scadenza, è necessario aggiornarli per continuare ad accedere alle risorse. Quando si aggiorna il token di accesso, Azure AD B2C restituisce un nuovo token. Il token di accesso aggiornato avrà aggiornato nbf (non prima di), iat (emesso il) e exp (scadenza) i valori delle attestazioni. Tutti gli altri valori di attestazione corrispondono al token di accesso rilasciato in origine.

Per aggiornare il token, inviare un'altra richiesta POST all'endpoint /token . Questa volta, specificare invece refresh_token di code:

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1

Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=00001111-aaaa-2222-bbbb-3333cccc4444 offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
Parametro Obbligatorio? Descrizione
{tenant} Obbligatorio Nome del tenant di Azure AD B2C
{politica} Obbligatorio Flusso utente usato per acquisire il token di aggiornamento originale. Non è possibile usare un flusso utente diverso in questa richiesta.
ID cliente Obbligatorio ID applicazione assegnato all'app nel portale di Azure.
segreto_cliente Sì, nelle applicazioni web Segreto dell'applicazione generato nel portale di Azure. I segreti client vengono usati in questo flusso per gli scenari di app Web, in cui il client può archiviare in modo sicuro un segreto client. Per gli scenari di app nativa (client pubblico), i segreti client non possono essere archiviati in modo sicuro e pertanto non vengono usati in questa chiamata. Se si usa un segreto del client, modificarlo periodicamente.
tipo_di_concessione Obbligatorio Tipo di concessione. Per questa parte del flusso del codice di autorizzazione, il tipo di concessione deve essere refresh_token.
scopo Consigliato Elenco di ambiti separati da spazi. Un singolo valore di ambito indica all'ID Microsoft Entra entrambe le autorizzazioni richieste. L'uso dell'ID client come ambito indica che l'app necessita di un token di accesso che può essere usato per il proprio servizio o l'API Web, rappresentato dallo stesso ID client. L'ambito offline_access indica che l'app necessita di un token di aggiornamento per l'accesso di lunga durata alle risorse. È anche possibile usare l'ambito openid per richiedere un token ID da Azure AD B2C.
uri_di_reindirizzamento Opzionale URI di reindirizzamento dell'applicazione in cui è stato ricevuto il codice di autorizzazione.
token di aggiornamento Obbligatorio Il token di aggiornamento originale acquisito nella seconda fase del flusso.

Una risposta con esito positivo del token è simile alla seguente:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
Parametro Descrizione
non prima di Ora in cui il token è considerato valido, in fase di validità.
tipo di token Valore del tipo di token. L'unico tipo supportato da Microsoft Entra ID è Bearer.
token di accesso Il JWT firmato che hai richiesto.
scopo Ambiti per cui il token è valido. È anche possibile usare gli ambiti per memorizzare nella cache i token per usarli in un secondo momento.
scade_in Periodo di tempo in cui il token è valido (in secondi).
token di aggiornamento Token di aggiornamento di OAuth 2.0. L'app può usare questo token per acquisire token aggiuntivi dopo la scadenza del token corrente. I token di aggiornamento sono di lunga durata e possono essere usati per mantenere l'accesso alle risorse per lunghi periodi di tempo. Per ulteriori informazioni, vedere il riferimento ai token di Azure AD B2C.

Le risposte di errore hanno un aspetto simile al seguente:

{
    "error": "access_denied",
    "error_description": "The user revoked access to the app.",
}
Parametro Descrizione
Errore Stringa di codice di errore che è possibile usare 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.

Utilizza la tua directory di Azure AD B2C

Per provare queste richieste, completare la procedura seguente. Sostituire i valori di esempio usati in questo articolo con valori personalizzati.

  1. Creare una directory di Azure AD B2C. Utilizzare il nome della directory nelle richieste.
  2. Creare un'applicazione per ottenere un ID applicazione e un URI di reindirizzamento. Includere un client nativo nell'app.
  3. Creare i flussi utente per ottenere i nomi dei flussi utente.