Token di autenticazione: tipi, usi e best practice

I token di autenticazione verificano l'identità, ma i token rubati aggirano la sicurezza. Scopri JWT, OAuth 2.0, SAML e i token hardware, gli errori comuni e le strategie di difesa. Scopri come SentinelOne rileva gli attacchi basati sull'identità in Active Directory ed Entra ID.

Che cos'è un token di autenticazione?

Immagina questo scenario: accedi alla tua applicazione aziendale alle 9 del mattino a New York. Trenta minuti dopo, qualcuno accede al tuo account da Tokyo. La tua password non è mai cambiata. Il tuo token di autenticazione a più fattori (MFA) è rimasto sulla tua scrivania. Ma un attaccante è appena entrato dalla porta principale usando un token di autenticazione rubato.

I token di autenticazione sono i badge digitali che verificano la tua identità nei sistemi aziendali. Sono credenziali crittografiche, quindi la tua password non viaggia mai con la richiesta. Secondo il NIST Special Publication 800-63B-4, questi token costituiscono la base dell'affidabilità dell'identità digitale nelle moderne architetture di cybersecurity.

Lo scenario sopra non è ipotetico. Nel 2023, un threat actor ha estratto token di sessione dai file di supporto caricati nel sistema di assistenza clienti di Okta e li ha usati per dirottare le sessioni attive di cinque clienti. Nessuna password è stata violata. Nessuna richiesta MFA ha ricevuto risposta. È stato presentato un token valido e il sistema ha fatto esattamente ciò per cui era stato progettato.

Capire come funzionano i token, dove falliscono e come proteggerli è ciò che distingue un'infrastruttura di autenticazione solida da un'infrastruttura che consegna a un attaccante le chiavi. Questa pagina illustra tutti e tre gli aspetti.

Perché i token di autenticazione sono obiettivi di sicurezza

I token si trovano all'intersezione tra la sicurezza dell'identità e l'architettura di controllo degli accessi. Quando ti autentichi su un sistema, non porti con te le tue credenziali effettive per ogni richiesta. Ricevi invece un token che dice "questa persona ha già dimostrato chi è".

Rubare un token consente a un attaccante di bypassare completamente l'autenticazione. Falsificarne uno gli permette di impersonare un utente legittimo. Manipolare il modo in cui un token viene convalidato consente di aumentare i privilegi senza mai disporre di un account autorizzato.

Il costo di questi errori è ben documentato. Il Cost of a Data Breach Report 2026 di IBM stima il costo medio globale di una violazione in 4,99 milioni di dollari, un massimo storico. Il Data Breach Investigations Report (DBIR) 2026 di Verizon ha rilevato che lo sfruttamento delle vulnerabilità ha superato le credenziali rubate come principale punto di ingresso delle violazioni per la prima volta nei 19 anni di storia del report. Le credenziali hanno occupato quella posizione fino a quest'anno, e un token rubato è una credenziale che ha già superato la porta d'ingresso.

Per comprendere questi rischi, i team di sicurezza devono prima riconoscere i diversi tipi di token distribuiti dalle organizzazioni e come ciascuno presenti considerazioni di sicurezza uniche.

Tipi di token di autenticazione

Le organizzazioni distribuiscono diversi tipi di token in base ai propri requisiti di sicurezza e casi d'uso.

• JSON Web Tokens (JWT): token autonomi che trasportano attestazioni codificate in una struttura header-payload-signature. I JWT consentono una verifica stateless in cui i server convalidano i token senza interrogazioni al database, rendendoli ideali per architetture di microservizi distribuite.
• OAuth 2.0 Tokens: il framework OAuth utilizza due tipi di token che lavorano insieme. Gli access token forniscono credenziali a breve durata per le chiamate API, mentre i refresh token ottengono nuovi access token senza una nuova autenticazione. Questa separazione limita i danni derivanti dal furto di token.
• SAML (Security Assertion Markup Language) Assertions: token basati su XML scambiati tra identity provider e service provider per il single sign-on aziendale. SAML rimane dominante negli ambienti aziendali legacy e negli scenari di federazione B2B.
• Session Tokens: identificatori generati dal server che collegano i browser allo stato di sessione lato server. A differenza dei JWT stateless, i token di sessione richiedono archiviazione sul server ma offrono capacità di revoca immediata.
• FIDO2/Hardware Tokens: autenticatori fisici che utilizzano crittografia a chiave pubblica tramite API WebAuthn. Questi token offrono resistenza al phishing tramite binding crittografico dell'origine, garantendo che le credenziali funzionino solo su siti legittimi.

Sebbene ogni tipo di token serva scopi diversi, tutti condividono elementi architetturali comuni che ne determinano la postura di sicurezza. È da questi componenti che inizia l'hardening.

Componenti principali dei token di autenticazione

I token di autenticazione contengono elementi specifici che ne determinano la postura di sicurezza e le capacità funzionali.

1. Struttura del token: i JWT sono costituiti da tre sezioni: header (specifica l'algoritmo di firma come RS256 o ES256), payload (contiene le attestazioni) e signature (garantisce l'integrità crittografica). Le asserzioni SAML utilizzano istruzioni in formato XML secondo le specifiche OASIS SAML V2.0.
2. Metadati del token: i token trasportano metadati nel loro payload. I timestamp di scadenza (claim exp) definiscono le finestre di validità, i claim issued-at (iat) stabiliscono l'età del token, il JWT ID (jti) fornisce identificatori univoci per il tracciamento della revoca e le restrizioni di audience (claim aud) impediscono il riutilizzo del token tra servizi.
3. Entropia della sessione: i token di sessione delle applicazioni web richiedono entropia minima generata tramite generatori di numeri pseudocasuali crittograficamente sicuri (CSPRNG).
4. Crittografia dei token hardware: i token FIDO2 combinano le API browser WebAuthn con il Client to Authenticator Protocol (CTAP). Le chiavi private non lasciano mai l'elemento sicuro e il binding crittografico dell'origine garantisce che le credenziali funzionino solo su siti web legittimi.

Questi componenti si combinano in workflow, ed è nel workflow che la sicurezza dei token si vince o si perde. Le sezioni seguenti tracciano ogni flusso, incluso il modo in cui i token interagiscono con l'autenticazione a più fattori.

Come funzionano i token di autenticazione

I token di autenticazione seguono workflow distinti a seconda del tipo e del contesto di distribuzione.

• Flusso di autenticazione JWT: invii le credenziali al server di autenticazione. Il server convalida le credenziali, genera e firma crittograficamente un JWT con claim di scadenza, audience ed emittente e lo restituisce al client. Per le richieste successive, includi il JWT nell'header Authorization. Il resource server convalida la firma e verifica i claim prima di concedere l'accesso.
• OAuth 2.0 Authorization Code Flow: richiedi l'accesso a una risorsa protetta. Dopo autenticazione e consenso, il server emette un authorization code che la tua applicazione scambia con access token e refresh token. Utilizzi access token a breve durata per le chiamate API e scambi refresh token con nuovi access token quando necessario.
• SAML Web Browser SSO: tenti di accedere a un'applicazione service provider, che ti reindirizza all'identity provider. Dopo l'autenticazione, l'IdP genera un'asserzione SAML firmata e la invia al service provider, stabilendo la tua sessione autenticata e abilitando il single sign-on su più applicazioni.
• Aggiornamento e rotazione dei token: gli access token a breve durata scadono frequentemente, richiedendo meccanismi di refresh. La rotazione dei token genera un nuovo refresh token ogni volta che ne usi uno, prevenendo gli attacchi di replay. Se qualcuno riutilizza un refresh token, il sistema rileva una potenziale compromissione e può revocare l'intera famiglia di token.
• Autenticazione con token hardware: registri il tuo autenticatore FIDO2 generando una coppia di chiavi nell'elemento sicuro del dispositivo. Durante l'autenticazione, il servizio invia una challenge crittografica che il tuo autenticatore firma con la chiave privata. Il servizio verifica la firma utilizzando la chiave pubblica registrata.

Se implementati correttamente, questi workflow giustificano la loro complessità. Ecco dove questo porta vantaggi.

Casi d'uso dei token di autenticazione

I token di autenticazione rispondono a requisiti specifici di sicurezza e operatività negli ambienti aziendali.

1. Single Sign-On aziendale: le asserzioni SAML consentono ai dipendenti di autenticarsi una sola volta e accedere a decine di applicazioni senza login ripetuti. Identity provider come Okta, Azure AD e Ping Federation emettono token di cui i service provider si fidano, riducendo l'affaticamento da password e centralizzando la governance degli accessi.
2. Sicurezza API e microservizi: gli access token OAuth 2.0 proteggono la comunicazione service-to-service nelle architetture distribuite. Ogni microservizio convalida in modo indipendente i token in ingresso, consentendo scalabilità stateless senza archivi di sessione condivisi.
3. Autorizzazione di terze parti: OAuth 2.0 abilita scenari "Login with Google" in cui gli utenti autorizzano le applicazioni ad accedere ai propri dati senza condividere password. Il server di autorizzazione emette token con scope che limitano ciò a cui le applicazioni possono accedere.
4. Sessioni di applicazioni mobili: i JWT forniscono autenticazione persistente per le app mobili. I token archiviati in iOS Keychain o Android KeyStore sopravvivono ai riavvii dell'app, offrendo esperienze utente fluide e mantenendo la sicurezza tramite archiviazione sicura specifica della piattaforma.
5. Autenticazione machine-to-machine: sistemi automatizzati e dispositivi IoT utilizzano grant client credentials per ottenere token per l'accesso API. Questi token autenticano job pianificati, sistemi di monitoraggio e comunicazioni dei dispositivi senza interazione umana.

Lo schema si mantiene in tutti questi casi. I token sostituiscono la trasmissione ripetuta delle credenziali con un'attestazione che il sistema ricevente può verificare autonomamente.

Principali vantaggi dei token di autenticazione

L'autenticazione basata su token supera la gestione tradizionale delle sessioni sotto quattro aspetti:

1. Scalabilità stateless: i sistemi basati su token eliminano i requisiti di archiviazione delle sessioni lato server, consentendo architetture di microservizi in cui i singoli servizi verificano in modo indipendente le credenziali senza stato condiviso.
2. Single Sign-On cross-domain: le asserzioni SAML 2.0 e OpenID Connect abilitano il single sign-on. Gli utenti si autenticano una sola volta e accedono a più applicazioni senza login ripetuti, centralizzando la governance dell'autenticazione.
3. Sicurezza API e Zero Trust: l'autenticazione service-to-service che utilizza client credentials OAuth 2.0 e JWT firmati impedisce ai servizi rogue di impersonare quelli affidabili, elemento essenziale per le architetture zero-trust.
4. Superficie di attacco ridotta: l'implementazione basata su standard protegge da attacchi specifici. I cookie HttpOnly impediscono l'accesso da JavaScript. Gli attributi SameSite bloccano gli attacchi Cross-Site Request Forgery (CSRF). I token FIDO2 ottengono resistenza al phishing tramite binding crittografico dell'origine.

Tuttavia, questi vantaggi comportano compromessi. Le stesse decisioni architetturali che consentono scalabilità e flessibilità introducono anche sfide che i team di sicurezza devono affrontare.

Sfide e limitazioni dei token di autenticazione

L'autenticazione basata su token introduce specifiche sfide operative e di sicurezza che richiedono un'attenta pianificazione architetturale.

1. Complessità della revoca dei token: la natura stateless che offre vantaggi di scalabilità crea difficoltà per la terminazione immediata dell'accesso. I token stateless rimangono validi fino alla scadenza, richiedendo o durate brevi che aumentano l'overhead di refresh, un'infrastruttura di blacklist dei token che annulla i vantaggi dello stateless, oppure l'accettazione di finestre di latenza della revoca.
2. Compromessi nella gestione della durata dei token: durate brevi degli access token limitano il danno potenziale in caso di compromissione ma richiedono continui scambi di refresh token. Durate lunghe migliorano l'esperienza utente ma creano finestre di esposizione più ampie se i token vengono rubati.
3. Archiviazione sicura dei token su piattaforme diverse: qualsiasi script in esecuzione nella pagina può leggere localStorage e sessionStorage, quindi una singola vulnerabilità di Cross-Site Scripting (XSS) trasforma entrambi in un elenco di token validi. L'approccio ibrido ampiamente adottato archivia i refresh token in cookie HttpOnly, mantiene gli access token in memoria e applica controlli CSRF sull'endpoint di refresh. Un access token in memoria è comunque esposto al memory dumping su un host compromesso, ed è proprio a questo che serve la endpoint security. Le applicazioni mobili richiedono archiviazione specifica della piattaforma: iOS Keychain conserva direttamente i token, mentre Android li cifra con una chiave conservata nell'Android Keystore. La comunicazione server-to-server deve essere gestita in un sistema di secret management come HashiCorp Vault o AWS Secrets Manager.
4. Rotazione delle chiavi e gestione crittografica: la rotazione delle chiavi negli ambienti di produzione introduce complessità di coordinamento. Le organizzazioni devono mantenere più chiavi di firma valide durante le finestre di rotazione, coordinare la rotazione tra servizi distribuiti e gestire correttamente la convalida dell'identificatore di chiave (kid).

Queste sfide di implementazione creano vulnerabilità specifiche che gli attaccanti sfruttano attivamente negli ambienti aziendali.

Errori comuni nell'implementazione dei token di autenticazione

La maggior parte delle violazioni dei token di autenticazione deriva da errori di implementazione piuttosto che da difetti crittografici. Comprendere questi errori comuni aiuta i team di sicurezza a dare priorità agli sforzi di hardening.

• Archiviazione lato client non sicura: archiviare i token di autenticazione nel localStorage o nel sessionStorage del browser rappresenta uno degli errori di implementazione più diffusi. Qualsiasi codice JavaScript eseguito nel contesto della pagina può accedere direttamente ai token di autenticazione ed esfiltrarli, rendendoli immediatamente vulnerabili agli attacchi XSS.
• Errori di convalida della firma: la mancata corretta convalida delle firme JWT crea vulnerabilità sfruttabili di bypass dell'autenticazione. Gli attacchi di algorithm confusion manipolano l'header dell'algoritmo da RS256 (asimmetrico) a HS256 (simmetrico), quindi firmano i token utilizzando la chiave pubblica come secret HMAC. I sistemi vulnerabili accettano questi token modificati, consentendo l'escalation dei privilegi. Questa vulnerabilità è stata documentata in CVE-2024-54150 con un punteggio di gravità CVSS 9.1 CRITICAL. Alcune implementazioni accettano token che specificano "alg: none", elaborando di fatto token non firmati come validi.
• Durata eccessiva dei token: impostare durate dei token troppo lunghe crea rischi di sicurezza persistenti. I token a lunga durata offrono agli attaccanti finestre di opportunità estese. Una volta compromessi tramite XSS o attacchi man-in-the-middle, i token con durata eccessiva consentono accessi non autorizzati per giorni o settimane anziché minuti.
• Assenza di meccanismi di revoca dei token: l'assenza di capacità di revoca dei token rappresenta una significativa lacuna architetturale. La compromissione dei Primary Refresh Tokens (PRT) utilizzati in implementazioni SSO come Azure AD si rivela particolarmente problematica. Senza meccanismi di revoca, le organizzazioni non possono terminare le sessioni compromesse in tempo reale, dovendo fare affidamento sulla naturale scadenza dei token.
• Gestione non sicura delle chiavi: i fallimenti nella gestione delle chiavi creano vulnerabilità sistemiche. Le vulnerabilità di SQL injection nei meccanismi di recupero delle chiavi possono esporre le chiavi di firma quando le applicazioni utilizzano query SQL vulnerabili per recuperare le chiavi JWT tramite il parametro kid. Archiviare informazioni sensibili nei payload JWT crea un'esposizione dei dati non necessaria perché i claim JWT sono solo codificati in base64 (non cifrati), risultando banalmente leggibili da chiunque abbia accesso al token.

Questi fallimenti hanno nomi e date. Nell'aprile 2022, un attaccante ha utilizzato token OAuth rubati da Heroku e Travis CI per scaricare repository privati da decine di organizzazioni, incluso npm. Il furto dei token di sessione Okta descritto all'inizio di questa pagina ha funzionato allo stesso modo: token validi, presentati dalla parte sbagliata, accettati senza alcuna verifica.

Ognuno di questi fallimenti è prevenibile e i controlli sono già documentati. Una difesa in profondità costruita su standard consolidati chiude le lacune su cui contano gli attaccanti.

Best practice per i token di autenticazione

Proteggere i token di autenticazione richiede l'implementazione di strategie di difesa in profondità basate su standard di sicurezza autorevoli come NIST SP 800-63B-4, OWASP e le specifiche IETF.

• Distribuire cookie HttpOnly e Secure: combina refresh token archiviati in cookie HttpOnly con access token mantenuti in memoria. Imposta il flag HttpOnly per impedire a JavaScript di accedere al contenuto dei cookie. Configura il flag Secure per garantire la trasmissione solo su connessioni HTTPS. Implementa l'attributo SameSite per la protezione CSRF.
• Implementare access token a breve durata con rotazione: configura la durata degli access token in base alla tolleranza al rischio. La rotazione dei token genera un nuovo refresh token ogni volta che ne usi uno, prevenendo gli attacchi di replay. Tieni traccia di tutti i refresh token emessi utilizzando i loro claim jti e invalida immediatamente i token precedenti dopo una rotazione riuscita.
• Applicare una rigorosa convalida della firma: rifiuta esplicitamente i token con "alg: none" specificato nell'header. Convalida che gli algoritmi di firma corrispondano ai tipi previsti, prevenendo gli attacchi di confusione RSA/HMAC. Utilizza query parametrizzate per il recupero delle chiavi per prevenire SQL injection.
• Distribuire il token binding: configura policy di Conditional Access per applicare il token binding, garantendo che i token non possano funzionare al di fuori dei dispositivi per cui sono stati originariamente emessi tramite integrazione con Trusted Platform Module (TPM) o Secure Enclave.
• Implementare un'infrastruttura di revoca: crea un tracciamento delle famiglie di token supportato da database utilizzando i claim jti. Crea interfacce amministrative per la revoca delle sessioni e distribuisci funzionalità di "logout everywhere" che consentano agli utenti di revocare tutte le sessioni quando sospettano una compromissione.

Anche con queste best practice in atto, attaccanti sofisticati continuano a trovare modi per compromettere i token. Quando la prevenzione non regge, ciò che conta è quanto rapidamente si individua l'abuso e quanto rapidamente si può intervenire.

Come SentinelOne rileva gli attacchi basati sull'identità

Singularity™ Platform offre rilevamento e risposta autonomi su endpoint, workload cloud e infrastruttura di identità. Nelle MITRE ATT&CK Evaluations: Enterprise 2024, SentinelOne ha registrato il 100% di rilevamento con l'88% di avvisi in meno rispetto alla mediana di tutti i fornitori valutati, una differenza che separa una coda di avvisi gestibile dai tuoi analisti da una che viene abbandonata. Purple AI™ accelera l'indagine stessa. Gli analisti fanno domande in linguaggio naturale e ricevono riepiloghi contestuali degli avvisi, con threat hunting fino all'80% più rapido.

Singularity Identity difende Active Directory ed Entra ID dalle minacce all'identità. I suoi rilevamenti si attivano sugli attacchi alle credenziali che colpiscono direttamente questi ambienti, incluso l'uso di ticket Kerberos rubati e falsificati per movimento laterale ed escalation dei privilegi. La tecnologia Storyline™ ricostruisce l'attacco mentre si sviluppa e correla gli eventi di autenticazione con il comportamento degli endpoint. Vedi l'intera catena, non un singolo avviso. Quando si attiva un rilevamento, la risposta autonoma contiene la minaccia, isola l'host e annulla il danno con rollback in 1 clic prima che il ransomware completi la cifratura. 

Richiedi una demo di SentinelOne per vedere il rilevamento basato sull'identità in esecuzione nel tuo ambiente.

Fai il tour

Ottieni protezione dell’identità in tempo reale e visibilità end-to-end negli ambienti ibridi per rilevare esposizioni, bloccare l’abuso delle credenziali e ridurre il rischio legato all’identità.

Punti chiave

Lo scenario dell'attacco da Tokyo dell'apertura? Si verifica quando un token rubato bypassa l'autenticazione senza mai toccare una password o una richiesta MFA. I token configurati in modo errato creano un'esposizione reale, eppure i token restano comunque essenziali. Ogni tipo ha un compito: JWT per microservizi stateless, OAuth 2.0 per l'autorizzazione API, SAML per l'SSO aziendale e FIDO2 per un'autenticazione resistente al phishing. Ognuno di essi diventa un vettore di attacco quando viene implementato con superficialità.

L'elenco delle correzioni è breve. Archivia i refresh token in cookie HttpOnly, mantieni gli access token in memoria, convalida rigorosamente le firme e ruota a ogni refresh. La maggior parte dei fallimenti in questa pagina deriva da una di queste attività non eseguite, più altre due che è più facile rimandare che costruire: infrastruttura di revoca e gestione delle chiavi.

Aggiungi XDR e identity threat detection and response (ITDR) in modo che un token nelle mani sbagliate emerga come rilevamento anziché come rilievo di audit sei mesi dopo. CVE-2024-54150 e gli otto gruppi nation-state tracciati nell' aggiornamento di ottobre 2024 di MITRE ATT&CK mostrano che lo sfruttamento dei token è attivo e attuale. I controlli che lo fermano esistono già, e sta a te implementarli.

FAQ

Che cos'è un token di autenticazione?

Un token di autenticazione è una credenziale crittografica che verifica la tua identità ai sistemi aziendali senza richiedere la trasmissione ripetuta del tuo nome utente e della tua password. Quando accedi a un'applicazione, il server emette un token come prova dell'avvenuta autenticazione. 

Il tuo dispositivo presenta questo token con ogni richiesta successiva, consentendo ai server di verificare la tua identità senza un secondo accesso. I formati comuni includono JSON Web Tokens (JWTs), token OAuth 2.0, asserzioni SAML e token FIDO2.

Qual è la differenza tra access token e refresh token?

I token di accesso forniscono credenziali di breve durata per accedere a risorse protette, in genere con scadenza entro pochi minuti secondo le raccomandazioni del NIST. I token di aggiornamento consentono di ottenere nuovi token di accesso quando quelli correnti scadono senza richiedere autenticazioni ripetute, con una durata tipica da giorni a settimane. 

Questo approccio a doppio token bilancia la sicurezza, grazie alla breve durata dei token di accesso, con l'esperienza utente. La rotazione dei token genera un nuovo token di aggiornamento a ogni utilizzo, invalidando il precedente per prevenire gli attacchi di replay.

Come fanno gli attaccanti a rubare i token di autenticazione?

Gli aggressori rubano token tramite attacchi XSS estraendo i token da localStorage, attacchi man-in-the-middle che intercettano la trasmissione, dump della memoria su endpoint compromessi, sfruttamento della pipeline CI/CD e dirottamento della sessione CSRF. 

Otto gruppi sponsorizzati da stati nazionali, tra cui APT28, APT29, APT41, Kimsuky, MuddyWater, OilRig, Sandworm Team e Turla, hanno aggiornato le capacità di attacco ai token nel 2024. La protezione richiede cookie HttpOnly, trasmissione sicura tramite HTTPS, associazione dei token ai dispositivi e monitoraggio comportamentale che rilevi  modelli di utilizzo anomali.

Come dovresti archiviare i token di autenticazione nelle applicazioni web?

Archivia i refresh token in cookie HttpOnly, Secure e SameSite che impediscono l'accesso da JavaScript e gli attacchi CSRF. Mantieni gli access token a breve durata in memoria anziché in localStorage o sessionStorage, evitando il furto basato su XSS. 

Per le app mobili, usa iOS Keychain o Android KeyStore. Per la comunicazione server, usa sistemi di gestione dei segreti come HashiCorp Vault o AWS Secrets Manager anziché variabili di ambiente o file di configurazione.

I token di autenticazione possono essere crittografati per una sicurezza aggiuntiva?

I JWT contengono claim codificati in base64 che chiunque abbia accesso al token può leggere. Per i dati sensibili, usa JWE (JSON Web Encryption), che fornisce la crittografia del payload tramite standard come RSA-OAEP-256 o AES-GCM. 

Tuttavia, una pratica migliore consiste nel non includere mai dati sensibili nei payload dei token. Archivia solo identificatori non sensibili come ID utente e ruoli. Mantieni gli attributi sensibili nei database backend, recuperandoli lato server tramite gli identificatori del token.

Che cos'è il token binding e come migliora la sicurezza?

Il binding del token collega crittograficamente i token di autenticazione allo specifico dispositivo su cui sono stati emessi, impedendo agli attaccanti di riutilizzare token rubati su sistemi diversi. Il token viene associato al Trusted Platform Module (TPM) o al Secure Enclave del dispositivo tramite prove crittografiche. 

Quando il token viene presentato, il server verifica sia la firma del token sia l’associazione al dispositivo. Microsoft Conditional Access e soluzioni analoghe di gestione delle identità aziendali supportano il binding del token per ambienti ad alta sicurezza.