Panoramica dei token in Azure Active Directory B2C

2025-05-01

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.

Azure Active Directory B2C (Azure AD B2C) genera diversi tipi di token di sicurezza durante l'elaborazione di ogni flusso di autenticazione. Questo articolo descrive il formato, le caratteristiche di sicurezza e il contenuto di ogni tipo di token.

Tipi di token

Azure AD B2C supporta i protocolli OAuth 2.0 e OpenID Connect, che usa i token per l'autenticazione e l'accesso sicuro alle risorse. Tutti i token usati in Azure AD B2C sono token Web JSON (JWT) che contengono asserzioni di informazioni sul bearer e sull'oggetto del token.

I token seguenti vengono usati nella comunicazione con Azure AD B2C:

Token ID : token JWT che contiene attestazioni che è possibile usare per identificare gli utenti nell'applicazione. Questo token viene inviato in modo sicuro nelle richieste HTTP per la comunicazione tra due componenti della stessa applicazione o servizio. È possibile usare le attestazioni in un token ID in base alle esigenze. Vengono comunemente usati per visualizzare le informazioni sull'account o per prendere decisioni di controllo di accesso in un'applicazione. I token ID emessi da Azure AD B2C sono firmati, ma non sono crittografati. Quando l'applicazione o l'API riceve un token ID, deve convalidare la firma per dimostrare che il token è autentico. L'applicazione o l'API deve anche convalidare alcune attestazioni nel token per dimostrare che è valida. A seconda dei requisiti dello scenario, le attestazioni convalidate da un'applicazione possono variare, ma l'applicazione deve eseguire alcune convalide di attestazioni comuni in ogni scenario.
Token di accesso : token JWT che contiene attestazioni che è possibile usare per identificare le autorizzazioni concesse alle API. I token di accesso sono firmati, ma non sono crittografati. I token di accesso vengono usati per fornire l'accesso alle API e ai server di risorse. Quando l'API riceve un token di accesso, deve convalidare la firma per dimostrare che il token è autentico. L'API deve anche convalidare alcune attestazioni nel token per dimostrare che è valida. A seconda dei requisiti dello scenario, le attestazioni convalidate da un'applicazione possono variare, ma l'applicazione deve eseguire alcune convalide di attestazioni comuni in ogni scenario.
Token di aggiornamento: i token di aggiornamento vengono usati per acquisire nuovi token ID e token di accesso in un flusso OAuth 2.0. Forniscono all'applicazione l'accesso a lungo termine alle risorse per conto degli utenti senza richiedere l'interazione con tali utenti. I token di aggiornamento sono opachi per l'applicazione. Vengono rilasciati da Azure AD B2C e possono essere controllati e interpretati solo da Azure AD B2C. Sono di lunga durata, ma l'applicazione non deve essere scritta con l'aspettativa che un token di aggiornamento durerà per un periodo di tempo specifico. I token di aggiornamento possono essere invalidati in qualsiasi momento per vari motivi. L'unico modo per sapere se un token di aggiornamento è valido è tentare di riscattarlo effettuando una richiesta di token ad Azure AD B2C. Quando si riscatta un token di aggiornamento per un nuovo token, si riceve un nuovo token di aggiornamento nella risposta del token. Salvare il nuovo token di aggiornamento. Sostituisce il token di aggiornamento usato in precedenza nella richiesta. Questa azione consente di garantire che i token di aggiornamento rimangano validi per il più tempo possibile. Le applicazioni a pagina singola che usano il flusso del codice di autorizzazione con PKCE hanno sempre una durata del token di aggiornamento di 24 ore. Altre informazioni sulle implicazioni di sicurezza dei token di aggiornamento nel browser.

Endpointi

Un'applicazione registrata riceve i token e comunica con Azure AD B2C inviando richieste a questi endpoint:

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/authorize
https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/token

I token di sicurezza che l'applicazione riceve da Azure AD B2C possono provenire dagli endpoint /authorize o /token. Quando i token ID vengono acquisiti da:

/authorize endpoint, viene eseguito utilizzando il flusso implicito, spesso impiegato dagli utenti per accedere alle applicazioni web basate su JavaScript. Tuttavia, se l'app utilizza MSAL.js 2.0 o versione successiva, non abilitare il flusso implicito nella registrazione dell'app, poiché MSAL.js 2.0+ supporta il flusso del codice di autorizzazione con PKCE.
/token endpoint, viene eseguito usando il flusso del codice di autorizzazione, che mantiene il token nascosto dal browser.

Richieste di rimborso

Quando si usa Azure AD B2C, è possibile controllare con granularità fine sul contenuto dei token. È possibile configurare i flussi utente e i criteri personalizzati per inviare determinati set di dati utente nelle attestazioni necessarie per l'applicazione. Queste attestazioni possono includere proprietà standard, ad esempio displayName e emailAddress. Le applicazioni possono usare queste attestazioni per autenticare in modo sicuro utenti e richieste.

Le attestazioni nei token ID non vengono restituite in un ordine specifico. È possibile introdurre nuove attestazioni nei token ID in qualsiasi momento. L'applicazione non dovrebbe interrompersi man mano che vengono introdotte nuove dichiarazioni. È anche possibile includere attributi utente personalizzati nelle attestazioni.

La tabella seguente elenca le attestazioni che è possibile prevedere nei token ID e nei token di accesso emessi da Azure AD B2C.

Nome	Richiesta di rimborso	Valore di esempio	Descrizione
Destinatari	`aud`	`00001111-aaaa-2222-bbbb-3333cccc4444`	Identifica il destinatario del token. Per Azure AD B2C, il gruppo di destinatari è l'ID applicazione. L'applicazione deve convalidare questo valore e rifiutare il token se non corrisponde. Il gruppo di destinatari è sinonimo di risorsa.
Emittente	`iss`	`https://<tenant-name>.b2clogin.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/`	Identifica il servizio token di sicurezza (STS) che costruisce e restituisce il token. Identifica anche la directory in cui l'utente è stato autenticato. L'applicazione deve convalidare l'attestazione dell'autorità emittente per assicurarsi che il token provenisse dall'endpoint appropriato.
Rilasciato all'indirizzo	`iat`	`1438535543`	Ora in cui è stato emesso il token, rappresentato in un periodo di tempo.
Ora di scadenza	`exp`	`1438539443`	Ora in cui il token non è valido, rappresentato in un periodo di tempo. L'applicazione deve usare questa attestazione per verificare la validità della durata del token.
Non prima	`nbf`	`1438535543`	Ora in cui il token diventa valido, rappresentato in un periodo di tempo. Questo orario è in genere uguale all'ora in cui il token è stato emesso. L'applicazione deve usare questa attestazione per verificare la validità della durata del token.
Versione	`ver`	`1.0`	Versione del token ID, come definito da Azure AD B2C.
Hash del codice	`c_hash`	`SGCPtt01wxwfgnYZy2VJtQ`	Hash del codice incluso in un token ID solo quando il token viene rilasciato insieme a un codice di autorizzazione OAuth 2.0. È possibile usare un hash del codice per convalidare l'autenticità di un codice di autorizzazione. Per altre informazioni su come eseguire questa convalida, vedere la specifica OpenID Connect.
Hash del token di accesso	`at_hash`	`SGCPtt01wxwfgnYZy2VJtQ`	Il hash del token di accesso è incluso in un token ID solo quando entrambi i token vengono emessi insieme a un token di accesso OAuth 2.0. È possibile usare un hash del token di accesso per convalidare l'autenticità di un token di accesso. Per altre informazioni su come eseguire questa convalida, vedere la specifica OpenID Connect
Nonce	`nonce`	`12345`	Un nonce è una strategia usata per attenuare gli attacchi di riproduzione dei token. L'applicazione può specificare un nonce in una richiesta di autorizzazione usando il `nonce` parametro di query. Il valore specificato nella richiesta viene emesso senza essere modificato solo nell'attestazione `nonce` di un token ID. Questa attestazione consente all'applicazione di verificare il valore rispetto al valore specificato nella richiesta. L'applicazione deve eseguire questa convalida durante il processo di convalida del token ID.
Oggetto	`sub`	`aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb`	L'entità principale su cui il token asserisce informazioni, come l'utente di un'applicazione. Questo valore non è modificabile e non può essere riassegnato o riutilizzato. Può essere usato per eseguire controlli di autorizzazione in modo sicuro, ad esempio quando il token viene usato per accedere a una risorsa. Per impostazione predefinita, l'attestazione dell'oggetto viene popolata con l'ID oggetto dell'utente nella directory.
Informazioni di riferimento sulla classe del contesto di autenticazione	`acr`	Non applicabile	Usato solo con le politiche vecchie.
Criteri del framework di attendibilità	`tfp`	`b2c_1_signupsignin1`	Nome del criterio usato per acquisire il token ID.
Tempo di autenticazione	`auth_time`	`1438535543`	Ora in cui un utente ha immesso le credenziali, rappresentate in un periodo di tempo. Non esiste alcuna discriminazione tra l'autenticazione come un nuovo accesso, una sessione single sign-on (SSO) o un altro tipo di accesso. `auth_time` è l'ultima volta che l'applicazione (o l'utente) ha avviato un tentativo di autenticazione contro Azure AD B2C. Il metodo usato per l'autenticazione non è differenziato.
Ambito	`scp`	`Read`	Autorizzazioni concesse alla risorsa per un token di accesso. Più autorizzazioni concesse sono separate da uno spazio.
Entità autorizzata	`azp`	`975251ed-e4f5-4efd-abcb-5f1a8f566ab7`	ID dell'applicazione client che ha avviato la richiesta.

Configurazione

Le proprietà seguenti vengono usate per gestire la durata dei token di sicurezza generati da Azure AD B2C:

Durata del token di accesso e ID (minuti): durata del token di connessione OAuth 2.0 usato per ottenere l'accesso a una risorsa protetta. Il valore predefinito è 60 minuti. Il valore minimo (inclusivo) è di 5 minuti. Il valore massimo (inclusivo) è 1.440 minuti.
Durata del token di aggiornamento (giorni): periodo di tempo massimo prima del quale è possibile usare un token di aggiornamento per acquisire un nuovo token di accesso o ID. Il periodo di tempo copre anche l'acquisizione di un nuovo token di aggiornamento se all'applicazione è stato concesso l'ambito offline_access . Il valore predefinito è 14 giorni. Il valore minimo (inclusivo) è un giorno. Il valore massimo (inclusivo) è 90 giorni.
Durata della finestra temporale temporale scorrevole del token di aggiornamento (giorni) - Dopo questo periodo di tempo trascorso, l'utente è costretto a ripetere l'autenticazione, indipendentemente dal periodo di validità del token di aggiornamento più recente acquisito dall'applicazione. Può essere fornito solo se l'opzione è impostata su Bounded. Deve essere maggiore o uguale al valore durata del token di aggiornamento (giorni). Se l'opzione è impostata su Nessuna scadenza, non è possibile specificare un valore specifico. Il valore predefinito è 90 giorni. Il valore minimo (inclusivo) è un giorno. Il valore massimo (inclusivo) è 365 giorni.

I casi d'uso seguenti sono abilitati usando queste proprietà:

Consentire a un utente di rimanere connessi a un'applicazione per dispositivi mobili per un periodo illimitato, purché l'utente sia continuamente attivo nell'applicazione. È possibile impostare Durata finestra temporale scorrevole del token di aggiornamento (giorni) su Nessuna scadenza nel flusso utente di accesso.
Soddisfare i requisiti di sicurezza e conformità del settore impostando la durata appropriata dei token di accesso.

Queste impostazioni non sono disponibili per i flussi utente di reimpostazione della password.

Compatibilità

Per gestire la compatibilità dei token vengono usate le proprietà seguenti:

Dichiarazione dell'emittente (iss): questa proprietà identifica il tenant di Azure AD B2C che ha emesso il token. Il valore predefinito è https://<domain>/{B2C tenant GUID}/v2.0/. Il valore di https://<domain>/tfp/{B2C tenant GUID}/{Policy ID}/v2.0/ include GLI ID sia per il tenant di Azure AD B2C che per il flusso utente usato nella richiesta di token. Se l'applicazione o la libreria richiede che Azure AD B2C sia conforme alla specifica OpenID Connect Discovery 1.0, usare questo valore.
Attestazione subject (sub): questa proprietà identifica l'entità per cui il token asserisce le informazioni. Il valore predefinito è ObjectID, che popola l'attestazione sub nel token con l'ID oggetto dell'utente. Il valore Non supportato è fornito solo per la compatibilità con le versioni precedenti. È consigliabile passare a ObjectID non appena è possibile.
Dichiarazione che rappresenta l'ID della politica - Questa proprietà identifica il tipo di dichiarazione in cui viene popolato il nome della politica usato nella richiesta di token. Il valore predefinito è tfp. Il valore di acr viene fornito solo per la compatibilità con le versioni precedenti.

Passaggio diretto

All'avvio di un percorso utente, Azure AD B2C riceve un token di accesso da un provider di identità. Azure AD B2C usa tale token per recuperare informazioni sull'utente. Si abilita un'attestazione nel flusso utente per passare il token alle applicazioni registrate in Azure AD B2C. L'applicazione deve usare un flusso utente consigliato per sfruttare il passaggio del token come attestazione.

Azure AD B2C supporta attualmente solo il passaggio del token di accesso dei provider di identità OAuth 2.0, tra cui Facebook e Google. Per tutti gli altri provider di identità, la dichiarazione viene restituita vuota.

Validazione

Per convalidare un token, l'applicazione deve controllare sia la firma che le attestazioni del token. Molte librerie open source sono disponibili per la convalida di JWT, a seconda del linguaggio preferito. È consigliabile esplorare queste opzioni anziché implementare la logica di convalida personalizzata.

Convalidare la firma

Un JWT contiene tre segmenti: un'intestazione, un corpo e una firma. Il segmento di firma può essere usato per convalidare l'autenticità del token in modo che possa essere considerato attendibile dall'applicazione. I token B2C di Azure AD vengono firmati usando algoritmi di crittografia asimmetrica standard del settore, ad esempio RSA 256.

L'intestazione del token contiene informazioni sulla chiave e sul metodo di crittografia usati per firmare il token:

{
        "typ": "JWT",
        "alg": "RS256",
        "kid": "GvnPApfWMdLRi8PDmisFn7bprKg"
}

Il valore dell'attestazione alg è l'algoritmo usato per firmare il token. Il valore della dichiarazione kid è la chiave pubblica utilizzata per firmare il token. In qualsiasi momento, Azure AD B2C può firmare un token usando una qualsiasi delle coppie di chiavi pubblica-privata. Azure AD B2C ruota periodicamente il set di chiavi possibile. L'applicazione deve essere scritta per gestire automaticamente le modifiche della chiave. Una frequenza ragionevole per verificare la disponibilità di aggiornamenti delle chiavi pubbliche usate da Azure AD B2C è ogni 24 ore. Per gestire le modifiche impreviste delle chiavi, l'applicazione dovrebbe essere progettata per recuperare nuovamente le chiavi pubbliche se riceve un valore kid imprevisto.

Azure AD B2C ha un endpoint di metadati OpenID Connect. Usando questo endpoint, le applicazioni possono richiedere informazioni su Azure AD B2C in fase di esecuzione. Queste informazioni includono endpoint, contenuto del token e chiavi di firma del token. Il tenant di Azure AD B2C contiene un documento di metadati JSON per ogni criterio. Il documento di metadati è un oggetto JSON che contiene diverse informazioni utili. I metadati contengono jwks_uri, che fornisce la posizione del set di chiavi pubbliche usate per firmare i token. Questa posizione viene fornita qui, ma è consigliabile recuperare la posizione in modo dinamico usando il documento di metadati e l'analisi jwks_uri:

https://contoso.b2clogin.com/contoso.onmicrosoft.com/b2c_1_signupsignin1/discovery/v2.0/keys

Il documento JSON che si trova in questo URL contiene tutte le informazioni sulla chiave pubblica in uso in un determinato momento. L'app può usare l'attestazione kid nell'intestazione JWT per selezionare la chiave pubblica nel documento JSON usato per firmare un token specifico. Può quindi eseguire la convalida della firma usando la chiave pubblica corretta e l'algoritmo indicato.

Il documento dei metadati per la politica B2C_1_signupsignin1 nel tenant contoso.onmicrosoft.com si trova in:

https://contoso.b2clogin.com/contoso.onmicrosoft.com/b2c_1_signupsignin1/v2.0/.well-known/openid-configuration

Per determinare quali criteri sono stati usati per firmare un token (e dove passare per richiedere i metadati), sono disponibili due opzioni. In primo luogo, il nome della politica viene incluso nell'attestazione tfp (predefinita) o acr (secondo la configurazione) nel token. È possibile estrarre le attestazioni dal corpo del token JWT decodificandolo in base-64 e deserializzando la stringa JSON risultante. L'attestazione tfp o acr è il nome del criterio usato per rilasciare il token. L'altra opzione consiste nel codificare i criteri nel valore del state parametro quando si rilascia la richiesta e quindi decodificarlo per determinare quale criterio è stato usato. Entrambi i metodi sono validi.

Azure AD B2C usa l'algoritmo RS256, basato sulla specifica RFC 3447 . La chiave pubblica è costituita da due componenti: il modulo RSA (n) e l'esponente pubblico RSA (e). È possibile convertire a livello di codice n e e i valori in un formato di certificato per la convalida del token.

Una descrizione di come eseguire la convalida della firma non rientra nell'ambito di questo documento. Molte librerie open source sono disponibili per la convalida di un token.

Convalidare le attestazioni

Quando le applicazioni o l'API ricevono un token ID, devono anche eseguire diversi controlli sulle attestazioni nel token ID. È necessario controllare le attestazioni seguenti:

audience: verifica che il token ID sia destinato alla tua applicazione.
non prima e ora di scadenza : verifica che il token ID non sia scaduto.
issuer : verifica che il token sia stato rilasciato all'applicazione da Azure AD B2C.
nonce : strategia per la mitigazione degli attacchi di riproduzione dei token.

Per un elenco completo delle convalide che l'applicazione deve eseguire, vedere la specifica OpenID Connect.

Altre informazioni su come usare i token di accesso.