Accesso Web con OpenID Connect - Azure AD B2C

2025-05-05

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.

OpenID Connect è un protocollo di autenticazione basato su OAuth 2.0, che può essere usato per consentire agli utenti di accedere in modo sicuro alle applicazioni Web. Usando l'implementazione di Azure Active Directory B2C (Azure AD B2C) di OpenID Connect, è possibile esternalizzare l'iscrizione, l'accesso e altre esperienze di gestione delle identità nelle applicazioni Web a Microsoft Entra ID. Questa guida illustra come eseguire questa operazione in modo indipendente dal linguaggio. Descrive come inviare e ricevere messaggi HTTP senza usare alcuna delle librerie open source.

Annotazioni

La maggior parte delle librerie di autenticazione open source acquisisce e convalida i token JWT per l'applicazione. È consigliabile esplorare queste opzioni anziché implementare il proprio codice. Per altre informazioni, vedere Panoramica di Microsoft Authentication Library (MSAL) e Microsoft Identity Web Authentication Library.

OpenID Connect estende il protocollo di autorizzazione OAuth 2.0 da usare come protocollo di autenticazione . Questo protocollo di autenticazione consente di eseguire l'accesso Single Sign-On. Introduce il concetto di token ID, che consente al client di verificare l'identità dell'utente e ottenere informazioni di base sul profilo sull'utente.

OpenID Connect consente anche alle applicazioni di acquisire in modo sicuro i token di accesso. È possibile usare i token di accesso per accedere alle risorse protette dal server di autorizzazione . È consigliabile usare OpenID Connect se si sta creando un'applicazione Web ospitata in un server e a cui si accede tramite un browser. Per altre informazioni sui token, vedere Panoramica dei token in Azure Active Directory B2C

Azure AD B2C estende il protocollo OpenID Connect standard per fare più che la semplice autenticazione e autorizzazione. Introduce il parametro del flusso utente, che consente di usare OpenID Connect per aggiungere esperienze utente all'applicazione, ad esempio la registrazione, l'accesso e la gestione dei profili.

Inviare richieste di autenticazione

Quando l'applicazione Web deve autenticare l'utente ed eseguire un flusso utente, può indirizzare l'utente all'endpoint /authorize . 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 specifica il flusso utente da eseguire. Per ottenere un'impressione del funzionamento della richiesta, incollare la richiesta nel browser ed eseguirla. Sostituire:

{tenant} con il nome dell'inquilino.
00001111-aaaa-2222-bbbb-3333cccc4444 con l'ID app di un'applicazione che hai registrato nel tuo tenant.
{application-id-uri}/{scope-name} con l'URI ID dell'applicazione e l'ambito di un'applicazione che hai registrato nel tuo tenant.
{policy} con il nome della politica presente nel tuo tenant, ad esempio b2c_1_sign_in.

GET /{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
Host: {tenant}.b2clogin.com

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code+id_token
&redirect_uri=https%3A%2F%2Fjwt.ms%2F
&response_mode=fragment
&scope=openid%20offline_access%20{application-id-uri}/{scope-name}
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345

Parametro	Obbligatorio	Descrizione
{tenant}	Sì	Nome del tenant di Azure AD B2C. Se si usa un dominio personalizzato, sostituire `tenant.b2clogin.com` con il dominio, ad esempio `fabrikam.com`.
{politica}	Sì	Il flusso utente o la politica eseguita dall'app. 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.
nonce	Consigliato	Un valore incluso nella richiesta (generato dall'applicazione) che viene trasformato in un'affermazione nel token ID risultante. L'applicazione può quindi verificare questo valore per attenuare gli attacchi di riproduzione dei token. Il valore è in genere una stringa univoca casuale che può essere usata per identificare l'origine della richiesta.
tipo_di_risposta	Sì	Deve includere un token ID per OpenID Connect. Se l'applicazione Web richiede anche token per chiamare un'API Web, è possibile usare `code+id_token`.
scopo	Sì	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. `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.
richiesta	NO	Tipo di interazione dell'utente necessario. L'unico valore valido in questo momento è `login`, che impone all'utente di immettere le credenziali per tale richiesta.
uri_di_reindirizzamento	Sì	Parametro `redirect_uri` dell'applicazione, in cui il server invia risposte di autenticazione all'applicazione. Deve corrispondere esattamente a uno dei `redirect_uri` parametri registrati nel portale di Azure, ad eccezione del fatto che deve essere codificato in URL.
modalità_di_risposta	NO	Metodo usato per inviare di nuovo il codice di autorizzazione risultante all'applicazione. Può essere `query`, `form_post`o `fragment`. È consigliabile usare la `form_post` modalità di risposta per garantire la sicurezza ottimale.
stato	NO	Valore che è possibile includere nella richiesta restituita dal server di autorizzazione nella risposta del token. Può essere una stringa di qualsiasi contenuto desiderato. Per evitare gli attacchi di falsificazione di richiesta intersito, viene normalmente usato un valore univoco generato casualmente. Lo stato viene usato anche per codificare informazioni sullo stato dell'utente nell'applicazione prima che si sia verificata la richiesta di autenticazione, ad esempio la pagina in cui si trovavano. Se non si vogliono registrare più URL di reindirizzamento nel portale di Azure, è possibile usare il `state` parametro per distinguere le risposte nell'applicazione dal servizio Azure AD B2C a causa di richieste diverse.
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 flusso di lavoro. L'utente potrebbe dover immettere il nome utente e la password, accedere con un'identità di social networking o iscriversi alla directory. Potrebbero essere presenti altri passaggi a seconda della modalità di definizione del flusso utente.

Dopo che l'utente ha completato il flusso utente, viene restituita una risposta all'applicazione in corrispondenza del parametro indicato redirect_uri , usando il metodo specificato nel response_mode parametro . La risposta è la stessa per ognuno dei casi precedenti, indipendentemente dal flusso utente.

Una risposta con esito positivo usando response_mode=fragment sarà simile alla seguente:

GET https://jwt.ms/#
id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=arbitrary_data_you_can_receive_in_the_response

Parametro	Descrizione
id_token (token di identificazione)	Token ID richiesto dall'applicazione. È possibile usare il token ID per verificare l'identità dell'utente e avviare una sessione con l'utente.
codice	Codice di autorizzazione richiesto dall'applicazione, se è stato usato `response_type=code+id_token`. L'applicazione può usare il codice di autorizzazione per richiedere un token di accesso per una risorsa di destinazione. I codici di autorizzazione scadono in genere dopo circa 10 minuti.
stato	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.

Le risposte agli errori possono anche essere inviate al redirect_uri parametro in modo che l'applicazione possa gestirle in modo appropriato:

GET https://jwt.ms/#
error=access_denied
&error_description=AADB2C90091%3a+The+user+has+cancelled+entering+self-asserted+information.%0d%0aCorrelation+ID%3a+xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx%0d%0aTimestamp%3a+xxxx-xx-xx+xx%3a23%3a27Z%0d%0a
&state=arbitrary_data_you_can_receive_in_the_response

Parametro	Descrizione
Errore	Codice che può essere usato per classificare i tipi di errori che si verificano.
descrizione_errore	Messaggio di errore specifico che consente di identificare la causa radice di un errore di autenticazione.
stato	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.

Convalidare il token ID

La semplice 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'applicazione. Azure AD B2C usa token WEB JSON (JWT) e la crittografia a chiave pubblica per firmare i token e verificare che siano validi.

Annotazioni

La maggior parte delle librerie di autenticazione open source convalida i token JWT per l'applicazione. È consigliabile esplorare queste opzioni anziché implementare la logica di convalida personalizzata. Per altre informazioni, vedere Panoramica di Microsoft Authentication Library (MSAL) e Microsoft Identity Web Authentication Library.

Azure AD B2C ha un endpoint di metadati OpenID Connect, che consente a un'applicazione di ottenere 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 B2C. Ad esempio, il documento di metadati per il flusso utente b2c_1_sign_in si trova in fabrikamb2c.onmicrosoft.com:

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 cui valore per lo stesso flusso utente sarà:

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

Per determinare quale flusso utente è stato usato per firmare un token ID, sono disponibili due opzioni. Prima di tutto, il nome del flusso utente è incluso nel claim acr del token ID, vedere claim che rappresenta il flusso utente. L'altra opzione consiste nel codificare il flusso utente nel valore del state parametro quando si emette la richiesta e quindi decodificarlo per determinare quale flusso utente è stato usato. Entrambi i metodi sono validi.

Dopo aver acquisito il documento di metadati dall'endpoint dei metadati OpenID Connect, è possibile usare le chiavi pubbliche RSA 256 per convalidare la firma del token ID. In questo endpoint potrebbero essere elencate più chiavi, ognuna identificata da un'attestazione kid . L'intestazione del token ID contiene anche un'attestazione kid , che indica quale di queste chiavi è stata usata per firmare il token ID.

Per verificare i token da Azure AD B2C, è necessario generare la chiave pubblica usando exponent(e) e modulus(n). A tale scopo, è necessario imparare a generare la chiave pubblica in un linguaggio di programmazione preferito. La documentazione ufficiale sulla generazione di chiavi pubbliche con il protocollo RSA è disponibile qui: https://tools.ietf.org/html/rfc3447#section-3.1

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.
Convalidare l'attestazione aud per assicurarsi che il token ID sia stato emesso per l'applicazione. Il valore dovrebbe essere l'ID dell'applicazione.
Validare le dichiarazioni iat e exp per assicurarsi che il token ID non sia scaduto.

Sono inoltre disponibili diverse altre convalide da eseguire. Le convalide sono descritte in dettaglio nella specifica OpenID Connect Core. È anche possibile convalidare più attestazioni, a seconda dello scenario. Alcune convalide comuni includono:

Assicurarsi che l'utente o l'organizzazione si sia iscritto all'applicazione.
Assicurarsi che l'utente disponga di autorizzazioni/privilegi appropriati.
Assicurarsi che si sia verificata una certa attendibilità dell'autenticazione, ad esempio l'autenticazione a più fattori Microsoft Entra.

Dopo aver convalidato il token ID, è possibile iniziare una sessione con l'utente. È possibile usare le attestazioni nel token ID per ottenere informazioni sull'utente nell'applicazione. Gli usi per queste informazioni includono la visualizzazione, i record e l'autorizzazione.

Ottenere un token

Se è necessario che l'applicazione Web esegua solo flussi utente, è possibile ignorare le sezioni successive. Queste sezioni sono applicabili solo alle applicazioni Web che devono effettuare chiamate autenticate a un'API Web, protetta da Azure AD B2C stesso.

È possibile riscattare il codice di autorizzazione acquisito (usando response_type=code+id_token) per un token alla risorsa desiderata inviando una POST richiesta 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. In questo caso, si usa l'ID client dell'app come ambito richiesto, che genera un token di accesso con tale ID client come "audience":

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Host: {tenant}.b2clogin.com
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

Parametro	Obbligatorio	Descrizione
{tenant}	Sì	Nome del tenant di Azure AD B2C
{politica}	Sì	Flusso utente usato per acquisire il codice di autorizzazione. Non è possibile usare un flusso utente diverso in questa richiesta. Aggiungere questo parametro alla stringa di query, non al corpo POST.
ID cliente	Sì	L'ID dell'applicazione assegnato dal portale di Azure alla tua applicazione.
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, pertanto non vengono usati in questo flusso. Se si usa un segreto del client, cambiarlo regolarmente.
codice	Sì	Codice di autorizzazione acquisito all'inizio del flusso utente.
tipo_di_concessione	Sì	Tipo di concessione, che deve essere `authorization_code` per il flusso del codice di autorizzazione.
uri_di_reindirizzamento	NO	Parametro `redirect_uri` dell'applicazione in cui è stato ricevuto il codice di autorizzazione.
scopo	NO	Elenco di ambiti separati da spazi. L'ambito `openid` indica un'autorizzazione per accedere all'utente e ottenere dati sull'utente sotto forma di parametri id_token. Può essere usato per ottenere token per l'API web back-end della propria applicazione, che è rappresentata dallo stesso ID dell'applicazione del client. L'ambito `offline_access` indica che l'applicazione necessita di un token di aggiornamento per l'accesso esteso alle risorse.

Una risposta di token con esito positivo ha un aspetto simile al seguente:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
    "expires_in": "3600",
    "expires_on": "1644254945",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}

Parametro	Descrizione
non prima di	Periodo in cui il token diventa valido.
tipo di token	Valore del tipo di token. `Bearer` è l'unico tipo supportato.
token di accesso	Il JWT firmato che hai richiesto.
scopo	Gli ambiti validi per il token.
scade_in	Periodo di tempo in cui il token di accesso è valido (in secondi).
scade_il	Periodo di tempo in cui il token di accesso non è valido.
token di aggiornamento	Token di aggiornamento di OAuth 2.0. L'applicazione può usare questo token per acquisire più token dopo la scadenza del token corrente. I token di aggiornamento possono essere usati per mantenere l'accesso alle risorse per lunghi periodi di tempo. L'ambito `offline_access` deve essere stato usato sia nelle richieste di autorizzazione che di token per ricevere un token di aggiornamento.

Le risposte di errore hanno un aspetto simile al seguente:

{
    "error": "invalid_grant",
    "error_description": "AADB2C90080: The provided grant has expired. Please re-authenticate and try again. Current time: xxxxxxxxxx, Grant issued time: xxxxxxxxxx, Grant expiration time: xxxxxxxxxx\r\nCorrelation ID: xxxxxxxx-xxxx-xxxX-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-16 xx:10:52Z\r\n"
}

Parametro	Descrizione
Errore	Codice che può essere usato per classificare i tipi di errori che si verificano.
descrizione_errore	Messaggio che consente di identificare la causa radice di un errore di autenticazione.

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...

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 sono simili a quelli del token di accesso precedente.

Aggiornare un token inviando un'altra POST richiesta all'endpoint /token . Questa volta specificare il refresh_token parametro anziché il code parametro :

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Host: {tenant}.b2clogin.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=openid offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob

Parametro	Obbligatorio	Descrizione
{tenant}	Sì	Nome del tenant di Azure AD B2C
{politica}	Sì	Flusso utente usato per acquisire il token di aggiornamento originale. Non è possibile usare un flusso utente diverso in questa richiesta. Aggiungere questo parametro alla stringa di query, non al corpo POST.
ID cliente	Sì	L'ID dell'applicazione assegnato dal portale di Azure alla tua applicazione.
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, pertanto non vengono usati in questa chiamata. Se si utilizza un segreto del cliente, per favore modificarlo periodicamente.
tipo_di_concessione	Sì	Tipo di concessione, che deve essere `refresh_token` per questa parte del flusso del codice di autorizzazione.
token di aggiornamento	Sì	Il token di aggiornamento originale che è stato acquisito nella seconda parte del flusso. L'ambito `offline_access` deve essere usato nelle richieste di autorizzazione e token per ricevere un token di aggiornamento.
uri_di_reindirizzamento	NO	Parametro `redirect_uri` dell'applicazione in cui è stato ricevuto il codice di autorizzazione.
scopo	NO	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. Può essere utilizzato per inviare token al back-end dell'API web della propria applicazione, che è identificato dallo stesso ID applicazione del client. L'ambito `offline_access` indica che l'applicazione necessita di un token di aggiornamento per l'accesso esteso alle risorse.

Una risposta di token con esito positivo ha un aspetto simile al 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...",
    "refresh_token_expires_in": "1209600"
}

Parametro	Descrizione
non prima di	Periodo in cui il token diventa valido.
tipo di token	Valore del tipo di token. `Bearer` è l'unico tipo supportato.
token di accesso	Il token JWT firmato richiesto.
scopo	Gli ambiti validi per il token.
scade_in	Periodo di tempo in cui il token di accesso è valido (in secondi).
token di aggiornamento	Token di aggiornamento di OAuth 2.0. L'applicazione può usare questo token per acquisire token aggiuntivi dopo la scadenza del token corrente. I token di aggiornamento possono essere usati per mantenere l'accesso alle risorse per lunghi periodi di tempo.
refresh_token_expires_in	Periodo di tempo in cui il token di aggiornamento è valido (in secondi).

Le risposte di errore hanno un aspetto simile al seguente:

{
    "error": "invalid_grant",
    "error_description": "AADB2C90129: The provided grant has been revoked. Please reauthenticate and try again.\r\nCorrelation ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-xx xx:xx:xxZ\r\n",
}

Parametro	Descrizione
Errore	Codice che può essere usato per classificare i tipi di errori che si verificano.
descrizione_errore	Messaggio che consente di identificare la causa radice di un errore di autenticazione.

Inviare una richiesta di disconnessione

Quando si vuole disconnettere l'utente dall'applicazione, non è sufficiente cancellare i cookie dell'applicazione o terminare la sessione con l'utente. Reindirizzare l'utente ad Azure AD B2C per disconnettersi. In caso contrario, l'utente potrebbe essere in grado di ripetere l'autenticazione all'applicazione senza immettere di nuovo le credenziali. Per altre informazioni, vedere Comportamento della sessione di Azure AD B2C.

Per disconnettere l'utente, reindirizzare l'utente all'oggetto end_session_endpoint elencato nel documento dei metadati openID Connect descritto in precedenza:

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

Parametro	Obbligatorio	Descrizione
{tenant}	Sì	Nome del tenant di Azure AD B2C. Se si usa un dominio personalizzato, sostituire `tenant.b2clogin.com` con il dominio, ad esempio `fabrikam.com`.
{politica}	Sì	Flusso utente specificato nella richiesta di autorizzazione. Ad esempio, se l'utente ha effettuato l'accesso tramite il flusso utente `b2c_1_sign_in`, specificare il `b2c_1_sign_in` nella richiesta di disconnessione.
id_token_hint	NO	Un token ID rilasciato in precedenza da fornire all'endpoint di logout per fornire un'indicazione sulla sessione autenticata corrente dell'utente finale con il client. `id_token_hint` garantisce che `post_logout_redirect_uri` sia un URL di risposta registrato nelle impostazioni dell'applicazione Azure AD B2C. Per ulteriori informazioni, vedere Proteggere il reindirizzamento del logout.
ID cliente	No*	L'ID dell'applicazione assegnato dal portale di Azure alla tua applicazione. * Questa operazione è necessaria quando si usa la `Application` configurazione SSO di isolamento e Richiedi token ID* nella richiesta di disconnessione è impostato su `No`.*
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. Se non si fornisce un `id_token_hint`, non dovresti registrare questo URL come URL di risposta nelle impostazioni dell'applicazione Azure AD B2C.
stato	NO	Se si include un `state` parametro nella richiesta di autorizzazione, il server di autorizzazione restituisce lo stesso valore nella risposta a `post_logout_redirect_uri`. L'applicazione deve verificare che il `state` valore nella richiesta e nella risposta sia identico.

Dopo una richiesta di disconnessione, Azure AD B2C invalida la sessione basata su cookie di Azure AD B2C e tenta di disconnettersi dai provider di identità federati. Per altre informazioni, vedere Single Sign-Out.

Assicurati di proteggere il reindirizzamento del logout

Dopo la disconnessione, l'utente viene reindirizzato all'URI specificato nel post_logout_redirect_uri parametro, indipendentemente dagli URL di risposta specificati per l'applicazione. Tuttavia, se viene passato un valore valido id_token_hint e l'opzione Richiedi token ID nelle richieste di disconnessione è attivata, Azure AD B2C verifica che il valore di post_logout_redirect_uri corrisponda a uno degli URI di reindirizzamento configurati dell'applicazione prima di eseguire il reindirizzamento. Se non è stato configurato alcun URL di risposta corrispondente per l'applicazione, viene visualizzato un messaggio di errore e l'utente non viene reindirizzato.

Per impostare il token ID richiesto nelle richieste di disconnessione, vedere Configurare il comportamento della sessione in Azure Active Directory B2C.

Altre informazioni sulla sessione di Azure AD B2C.

Condividi tramite

Accesso al Web con OpenID Connect in Azure Active Directory B2C