Accesso Web con OpenID Connessione in Azure Active Directory B2C

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 Connessione, è possibile esternalizzare l'iscrizione, l'accesso e altre esperienze di gestione delle identità nelle applicazioni Web all'ID Microsoft Entra. Questa guida illustra come eseguire questa operazione in modo indipendente dal linguaggio. La guida descrive come inviare e ricevere messaggi HTTP senza usare una delle librerie Microsoft open source.

Nota

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 per consentirne l'uso come protocollo di autenticazione. Questo protocollo di autenticazione supporta l'accesso Single Sign-On. Introduce il concetto di token ID, che consente al client di verificare l'identità dell'utente e di ottenere informazioni di base sul profilo dell'utente.

OpenID Connessione 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 Connessione se si sta creando un'applicazione Web ospitata in un server e 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 standard OpenID Connect per non limitarsi esclusivamente a semplici operazioni di autenticazione e autorizzazione. Introduce il parametro del flusso utente, che consente di usare OpenID Connessione per aggiungere esperienze utente all'applicazione, ad esempio la gestione di iscrizione, accesso e profilo.

Invio di 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. Sostituzione:

  • {tenant} con il nome del tenant.
  • 90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 con l'ID app di un'applicazione registrata nel tenant.
  • {application-id-uri}/{scope-name} con l'URI ID applicazione e l'ambito di un'applicazione registrata nel tenant.
  • {policy} con il nome del criterio presente nel tenant, ad esempio b2c_1_sign_in.
GET /{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
Host: {tenant}.b2clogin.com

client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&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 Richiesto Descrizione
{tenant} Nome del tenant di Azure AD B2C. Se si usa un dominio personalizzato, sostituire tenant.b2clogin.com con il dominio, ad esempio fabrikam.com.
{policy} Flusso utente o criterio eseguito dall'app. Specificare il nome di un flusso utente creato nel tenant di Azure AD B2C. Ad esempio: b2c_1_sign_in, b2c_1_sign_up o b2c_1_edit_profile.
client_id ID applicazione assegnato al portale di Azure all'applicazione.
nonce Valore incluso nella richiesta (generata dall'applicazione) inclusa nel token ID risultante come attestazione. L'applicazione può quindi verificare questo valore per attenuare gli attacchi di riproduzione dei token. Il valore è in genere una stringa casuale univoca che può essere usata per identificare l'origine della richiesta.
response_type Deve includere un token ID per Connessione OpenID. Se l'applicazione Web richiede anche token per chiamare un'API Web, è possibile usare code+id_token.
ambito Elenco di ambiti separato 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.
prompt No Tipo di interazione dell'utente necessario. L'unico valore valido in questa fase è login, che impone all'utente di immettere le credenziali per la richiesta.
redirect_uri 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 nella portale di Azure, ad eccezione del fatto che deve essere codificato in URL.
response_mode 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.
state No Valore che è possibile includere nella richiesta restituita dal server di autorizzazione nella risposta del token. Può trattarsi di una stringa di qualsiasi contenuto. Per evitare gli attacchi di richiesta intersito falsa, viene in genere 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.
login_hint No Può essere usato per precompilare il campo del nome di accesso della pagina di accesso. Per altre informazioni, vedere Prepopulate the sign-in name .For more information, see Prepopulate the sign-in name.
domain_hint No Fornisce un suggerimento ad Azure AD B2C sul provider di identità di social networking che deve essere usato per l'accesso. Se viene incluso un valore valido, l'utente passa direttamente alla pagina di accesso del provider 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 che utilizza response_mode=fragment ha un aspetto simile al seguente:

GET https://jwt.ms/#
id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=arbitrary_data_you_can_receive_in_the_response
Parametro Descrizione
id_token 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.
state 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
error Codice che può essere usato per classificare i tipi di errori che si verificano.
error_description Messaggio di errore specifico che consente di identificare la causa radice di un errore di autenticazione.
state 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.

Nota

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 Connessione, che consente a un'applicazione di ottenere informazioni su Azure AD B2C in fase di esecuzione. Queste informazioni includono endpoint, contenuti del token e chiavi per la firma dei token. È disponibile un documento di metadati JSON per ogni flusso utente nel tenant B2C. Ad esempio, il documento di metadati del flusso utente b2c_1_sign_in in fabrikamb2c.onmicrosoft.com si trova in:

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

Una delle proprietà del documento di configurazione è jwks_uri, il cui valore per lo stesso flusso utente è:

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 nell'attestazione acr nel token ID, vedere attestazione che rappresenta il flusso utente. In secondo luogo, è possibile codificare il flusso utente nel valore del parametro state quando si rilascia la richiesta, per poi decodificarlo e determinare quale flusso utente è stato usato. Entrambi i metodi sono validi.

Dopo aver acquisito il documento di metadati dall'endpoint di metadati OpenID Connessione, è 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 quali di queste chiavi sono state usate 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. Ad esempio:

  • Convalidare l'attestazione nonce per impedire attacchi di riproduzione dei token. Il valore deve corrispondere a quello specificato nella richiesta di accesso.
  • Convalidare l'attestazione aud per assicurarsi che il token ID sia stato emesso per l'applicazione. Il valore deve essere l'ID applicazione dell'applicazione.
  • Convalidare le iat attestazioni e exp per assicurarsi che il token ID non sia scaduto.

Esistono numerose altre convalide che è consigliabile eseguire. Le convalide sono descritte in dettaglio nella specifica OpenID Connessione 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 di queste informazioni includono la visualizzazione, i record e l'autorizzazione.

Acquisizione di 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, tramite response_type=code+id_token, per un token nella 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. In questo caso, si usa l'ID client dell'app come ambito richiesto, che genera 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
Host: {tenant}.b2clogin.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
Parametro Richiesto Descrizione
{tenant} Nome del tenant di Azure AD B2C
{policy} 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.
client_id ID applicazione assegnato al portale di Azure all'applicazione.
client_secret Sì, in App 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 client, modificarlo periodicamente.
codice Codice di autorizzazione acquisito all'inizio del flusso utente.
grant_type Tipo di concessione, che deve essere authorization_code per il flusso del codice di autorizzazione.
redirect_uri No Parametro redirect_uri dell'applicazione dove è stato ricevuto il codice di autorizzazione.
ambito No Elenco di ambiti separato da spazi. L'ambito openid indica un'autorizzazione per l'accesso dell'utente e per ottenere i dati relativi all'utente sotto forma di parametri id_token. Può essere usato per ottenere token all'API Web back-end dell'applicazione, rappresentata 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": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
    "expires_in": "3600",
    "expires_on": "1644254945",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
Parametro Descrizione
not_before Periodo in cui il token diventa valido.
token_type Valore del tipo di token. Bearer è l'unico tipo supportato.
access_token Il token JWT firmato richiesto.
ambito Ambiti validi per il token.
expires_in Periodo di validità del token di accesso (in secondi).
expires_on 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 si presentano nel modo 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
error Codice che può essere usato per classificare i tipi di errori che si verificano.
error_description Messaggio che consente di identificare la causa radice di un errore di autenticazione.

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

Aggiornamento del token

I token di accesso e i token ID hanno breve durata. È necessario aggiornarli dopo la scadenza 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), iat (rilasciato all'indirizzo) e exp (scadenza) i valori dell'attestazione. 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 . Specificare questa volta il parametro refresh_token al posto del parametro code:

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=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=openid offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
Parametro Richiesto Descrizione
{tenant} Nome del tenant di Azure AD B2C
{policy} 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.
client_id ID applicazione assegnato al portale di Azure all'applicazione.
client_secret Sì, in App 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 usa un segreto client, modificarlo periodicamente.
grant_type Tipo di concessione, che deve essere refresh_token per questa parte del flusso del codice di autorizzazione.
token di aggiornamento Token di aggiornamento originale 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.
redirect_uri No Parametro redirect_uri dell'applicazione dove è stato ricevuto il codice di autorizzazione.
ambito No Elenco di ambiti separato 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 usato per inviare token all'API Web back-end dell'applicazione, rappresentata 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": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
    "refresh_token_expires_in": "1209600"
}
Parametro Descrizione
not_before Periodo in cui il token diventa valido.
token_type Valore del tipo di token. Bearer è l'unico tipo supportato.
access_token Token JWT firmato richiesto.
ambito Ambiti validi per il token.
expires_in Periodo di validità del token di accesso (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 si presentano nel modo 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
error Codice che può essere usato per classificare i tipi di errori che si verificano.
error_description 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 di metadati Connessione OpenID 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 Richiesto Descrizione
{tenant} Nome del tenant di Azure AD B2C. Se si usa un dominio personalizzato, sostituire tenant.b2clogin.com con il dominio, ad esempio fabrikam.com.
{policy} Flusso utente specificato nella richiesta di autorizzazione. Ad esempio, se l'utente ha eseguito l'accesso con il b2c_1_sign_in flusso utente, specificare b2c_1_sign_in nella richiesta di disconnessione.
id_token_hint No Token ID rilasciato in precedenza da passare all'endpoint di disconnessione come suggerimento 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 altre informazioni, vedere Proteggere il reindirizzamento della disconnessione.
client_id No* ID applicazione assegnato al portale di Azure all'applicazione.

*Questa operazione è necessaria quando si usa la Application configurazione SSO di isolamento e Richiedi token ID nella richiesta di disconnessione è impostato su No.
post_logout_redirect_uri 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. A meno che non si fornisca un id_token_hintoggetto , non è consigliabile registrare questo URL come URL di risposta nelle impostazioni dell'applicazione Azure AD B2C.
state 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.

Proteggere il reindirizzamento della disconnessione

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.

Passaggi successivi