ID Token vs Access Token: la differenza cruciale in OpenID Connect

By Mirko Peters · 2026-10-28

Scopri le differenze fondamentali tra ID token e access token in OpenID Connect, e capisci perché confonderli può generare gravi falle di sicurezza.

Automatically translated with AI from the original post. Read the English original

Comprendere la differenza tra ID token e access token è fondamentale per sviluppatori e amministratori IT che lavorano con l'autenticazione moderna. Mentre OAuth 2.0 gestisce le autorizzazioni, OpenID Connect introduce l'ID token per confermare l'identità dell'utente. Confondere questi due token distinti porta a gravi vulnerabilità di sicurezza nelle applicazioni cloud.

Punti chiave

• Gli ID token dimostrano l'identità di un utente, mentre gli access token concedono autorizzazione e permessi.
• Confondere questi due token è un errore primario nella sicurezza delle applicazioni sviluppate internamente.
• OpenID Connect aggiunge la conferma dell'identità sopra il framework OAuth 2.0.
• Gli access token possono essere revocati, offrendo una postura di sicurezza più sicura rispetto alla memorizzazione delle password.
• Le app devono verificare crittograficamente gli ID token in arrivo invece di fidarsi ciecamente di essi.

Il dilemma centrale: identità contro autorizzazione

Nell'evoluzione delle moderne applicazioni web, gli sviluppatori si trovano spesso di fronte a confusione su come gli utenti effettuano l'accesso e su come interagiscono con i dati sottostanti. Gran parte di questa confusione deriva da una terminologia sovrapposta nell'ambito dell'identità. Quando le applicazioni hanno iniziato a diffondersi rapidamente sul web, affidarsi esclusivamente a semplici combinazioni di nome utente e password ha creato un enorme collo di bottiglia per la sicurezza. Gli utenti erano esausti di gestire decine di credenziali diverse, e questo portava al riutilizzo delle password su più piattaforme.

Per risolvere in parte questo problema è arrivato OAuth 2.0. Tuttavia, OAuth 2.0 non è mai stato progettato per rispondere alla domanda su chi sia una persona. Il suo scopo è fornire dei «permessi di accesso», noti come access token, che consentono a un'applicazione di raggiungere specifici endpoint dei dati per conto di un utente. Un access token descrive ciò che un'applicazione può fare, ma non dice nulla sull'identità della persona che lo possiede. Questa lacuna fondamentale ha fatto sì che le aziende che tentavano di creare esperienze di single sign-on dovessero aggiungere a OAuth dei controlli di identità personalizzati, con implementazioni frammentate che raramente erano coerenti tra loro.

OpenID Connect ha colmato esattamente questa lacuna introducendo un livello standardizzato pensato specificamente per l'autenticazione. Utilizzando un secondo token accanto al tradizionale access token, OpenID Connect separa nettamente la questione dell'identità da quella delle autorizzazioni. Tenere separati questi due concetti è il cambiamento di mentalità più importante per chiunque oggi sviluppi o verifichi applicazioni cloud.

Anatomia dell'ID token: cosa contiene

Quando un utente fa clic sul pulsante «Accedi con Microsoft», il provider di identità elabora le credenziali, gestisce i requisiti di autenticazione a più fattori e infine rimanda l'utente all'applicazione accompagnato da un ID token. Questo token è strutturato come JSON Web Token, comunemente abbreviato in JWT e pronunciato «giot». A prima vista un JWT appare come una stringa impenetrabile di caratteri separati da punti. Eppure, una volta decodificato, la sua struttura interna è sorprendentemente semplice.

All'interno di un ID token troverai alcuni claim standard, ciascuno con uno scopo preciso:

• Issuer: identifica il provider di identità specifico (come Microsoft Entra ID) che ha generato e firmato il token.
• Subject (sub): Funge da identificatore univoco e immutabile dell'utente. È progettato in modo cruciale per non cambiare nemmeno se l'utente aggiorna il proprio nome visualizzato o l'indirizzo email.
• Audience (aud): Specifica l'applicazione esatta per cui è stato creato il token, garantendo che un token destinato a un'app non possa essere intercettato e riutilizzato in modo malevolo da un'altra.
• Timestamp: Indica quando il token è stato emesso, quando scade e il momento esatto in cui l'utente si è autenticato.
• Nonce: Funziona come un numero di ricevuta sicuro che collega il token risultante alla specifica sessione di accesso che ha avviato la richiesta, bloccando efficacemente gli attacchi di replay.

È fondamentale che l'intero pacchetto sia firmato con la chiave privata del provider. L'applicazione ricevente convalida questa firma usando la chiave pubblica corrispondente pubblicata dal provider. Senza questa verifica crittografica, un ID token non è altro che una nota non verificata passata tra le parti.

Il pericolo di trattare l'identità come accesso

Uno degli anti-pattern più pericolosi nello sviluppo di applicazioni è trattare un ID token come una chiave di autorizzazione. Poiché un ID token conferma che un utente è John Doe di una specifica organizzazione, gli sviluppatori alle prime armi a volte commettono l'errore di usare questa conferma per concedere diritti amministrativi o accesso illimitato al database. Questo significa fraintendere completamente l'architettura.

Un ID token si limita a dichiarare chi si trova alla porta d'ingresso; non dice nulla sul fatto che quella persona possa entrare in ogni stanza o premere un determinato pulsante amministrativo. La logica di autorizzazione deve essere gestita separatamente dall'applicazione, tramite controllo degli accessi basato sui ruoli (RBAC) o meccanismi simili, usando l'identità verificata come punto di partenza e non come decisione finale di autorizzazione.

Inoltre, le applicazioni commettono spesso l'errore di accettare ID token in ingresso senza eseguire controlli di convalida adeguati. Fidarsi ciecamente di un token solo perché una libreria lo ha elaborato dietro le quinte lascia i sistemi esposti a dati falsificati. Verificare la firma, controllare i timestamp di scadenza e validare la claim audience sono passaggi indispensabili per mantenere una postura di sicurezza solida.

Conclusione

Padroneggiare il confine tra identità e autorizzazione aiuta a fare chiarezza sull'architettura cloud moderna. Se gli ID token si limitano a dimostrare chi è davanti alla tastiera e lasciano ai token di accesso il compito di stabilire quali azioni sono consentite, gli sviluppatori possono creare integrazioni robuste e sicure con piattaforme come Microsoft Entra ID. Per ascoltare un'analisi completa di questi concetti e scoprire come funzionano i moderni flussi di accesso nell'ecosistema Microsoft, guarda la discussione completa. Ascolta l'episodio completo e approfondisci oggi stesso i meccanismi dell'identità nel cloud!

Domande frequenti

Un ID token può essere usato per chiamare API o accedere a risorse protette?

No. Un ID token contiene solo claim di identità che descrivono chi è l'utente. Per chiamare API o accedere a risorse protette, un'applicazione deve usare un access token emesso tramite OAuth 2.0.

Perché OpenID Connect e OAuth 2.0 usano token separati?

Separare identità e autorizzazione consente alle applicazioni di verificare chi sta effettuando l'accesso senza concedere a tale applicazione il permesso illimitato di manipolare i dati o le risorse sottostanti dell'utente.

Che cosa succede se un'applicazione accetta un ID token senza verificarne la firma?

Saltare la verifica della firma espone l'applicazione a token falsificati, perché chiunque potrebbe generare una stringa personalizzata che si finge un utente valido.

Dove si inserisce il valore "nonce" nello scambio dei token?

Il nonce è una stringa casuale generata all'inizio del flusso di accesso e incorporata nell'ID token, che consente all'applicazione di prevenire gli attacchi di replay.