Scopri cosa sono i bearer token, come funzionano in OAuth 2.0 e JWT, la differenza rispetto agli access token e le migliori pratiche.
Dietro quasi ogni accesso moderno ad app o richiesta API si trova un instancabile protagonista silenzioso: il bearer token. Forse non lo noti, ma è presente ogni volta che colleghi servizi, esegui l’accesso o recuperi dati dal cloud.
Questa guida spiega cosa fanno i bearer token, perché sono importanti e come gestirli in sicurezza.
Un bearer token è un dato, di solito una stringa di caratteri, che dimostra che il possessore può accedere a una risorsa. L’aspetto chiave è che chiunque possegga il token può utilizzarlo, senza dover fornire ulteriori prove.
Pensa alla carta d’imbarco di un aereo. Una volta che ce l’hai in mano, puoi passare i controlli e salire a bordo. Nessuno ti chiede più l’ID se la carta è valida. Allo stesso modo, un bearer token permette alla tua applicazione di “salire sull’API” senza ricontrollare la tua identità ogni volta.
Per esempio, dopo aver effettuato l’accesso a Spotify sul telefono, non devi inserire la password ogni volta che ascolti una canzone. L’app memorizza invece un bearer token che dice ai server di Spotify: “questa richiesta arriva da un utente autorizzato.”
Il flusso dei bearer token può essere suddiviso in alcuni passaggi:
L’utente effettua l’accesso
Supponiamo che tu acceda ad un’app bancaria con username e password.
Il provider d’identità rilascia un token
Dopo la verifica, il server di autenticazione restituisce un bearer token. Questo potrebbe apparire così:
Il client usa il token
Ogni volta che tocchi “Controlla saldo” o “Trasferisci denaro”, l’app include il token nella richiesta HTTP:
L’API lo valida
Il server controlla che il token sia ancora valido, non scaduto e abbia le autorizzazioni corrette (ad esempio read:balance o write:transfer).
Accesso consentito
Se tutti i controlli sono superati, il server risponde con le informazioni richieste.
Questo modello è ampiamente utilizzato in servizi come le API di GitHub, dove gli sviluppatori si autenticano con un bearer token invece di inserire le credenziali ogni volta.
I bearer token sono diventati popolari perché hanno risolto problemi comuni della sicurezza web. A differenza delle sessioni lato server, non è necessario memorizzare dati per ogni utente connesso. Piuttosto, il token stesso contiene informazioni sufficienti perché il server possa validare le richieste.
Per esempio, in un’architettura a microservizi, dove decine di servizi comunicano tra loro, mantenere un archivio centralizzato delle sessioni è complesso e inefficiente. Con i bearer token, ogni servizio può validare le richieste in modo indipendente, mantenendo il sistema agile e scalabile.
Un esempio concreto: le API di Slack fanno largo uso dei bearer token. Quando crei un bot per Slack, ricevi un token che permette al bot di chiamare gli endpoint di Slack senza mantenere una sessione per ogni utente.
Molti bearer token sono implementati come JWT (JSON Web Token). Questi token sono stringhe codificate che includono informazioni sull’utente e le sue autorizzazioni.
Decodifichiamo un esempio di JWT:
Questo significa:
sub: Il soggetto, ovvero l’ID univoco dell’utente.name: Il nome dell’utente.iat: Timestamp di emissione.exp: Tempo di scadenza (quando il token diventa invalido).scope: Le autorizzazioni, in questo caso consentono all’app di leggere e scrivere messaggi.In pratica, se il token di Jane avesse solo lo scope read:messages, l’app potrebbe recuperare i suoi messaggi ma non inviare nuovi messaggi a suo nome.
È facile confondere bearer token e access token, perché spesso appaiono insieme. In realtà, sono correlati ma non identici.
Un access token è una credenziale che rappresenta l’autorizzazione di un utente ad accedere a una risorsa. Porta informazioni come:
Pensa a un permesso firmato dal preside. Dice all’insegnante (l’API) che puoi partecipare alla gita (accedere alla risorsa).
Ad esempio, quando accedi a un servizio di cloud storage, il sistema rilascia un access token con lo scope read:files. Quel token dice all’API di storage: “Questo utente può leggere i file, ma non eliminarli.”
Un bearer token è un tipo di access token. La parola bearer descrive come viene usato il token: chi lo presenta può “portarlo” per accedere alle risorse, senza bisogno di ulteriori prove d’identità.
In altre parole:
Esistono altri tipi di token, come i holder-of-key token, che richiedono al client di dimostrare il possesso di una chiave crittografica oltre al token. I bearer token saltano questo passaggio, risultando più semplici ma anche più rischiosi se rubati.
<token>.Questo significa che quando nei tutorial OAuth si parla di “access token”, quasi sempre si intende un bearer token, salvo diversa indicazione.
Per chiarire meglio, ecco un confronto tra bearer token e altri tipi comuni di token:
Bearer token e access token non sono concetti opposti — sono collegati per ambito:
La validazione di un bearer token è ciò che separa la tua API da accessi non autorizzati. Se i tuoi token sono JWT, la validazione avviene localmente e rapidamente. L’API può controllare il token senza contattare il provider ogni volta.
Usa questa lista come guida per configurare una API gateway o un middleware.
Firma
Verifica la firma usando l’algoritmo nell’header (per esempio RS256). Ottieni l’endpoint JWKS dell’emittente, seleziona la chiave corrispondente al kid e memorizzala in cache.
Issuer (iss)
Confronta l’iss del token con l’URL dell’emittente affidabile, esattamente e con lo schema corretto.
Audience (aud)
Assicurati che il token sia destinato alla tua API. Confronta con il tuo identificatore di API come https://api.example.com o una stringa logica di audience.
Scadenza (exp) e Not-Before (nbf)
Rifiuta i token scaduti. Rispetta il nbf in modo che il token non possa essere usato prima dell’ora di inizio. Consenti un piccolo margine di errore sull’orologio, di solito 30-60 secondi.
Emesso alle (iat)
Utile per il debug e per rifiutare token troppo vecchi in configurazioni restrittive.
Tipo di token
Verifica che sia un access token. Alcuni provider includono typ: "at+jwt" o simili. Non accettare ID token per l’accesso alle API.
Scope / permessi
Leggi lo scope o le claim specifiche del provider (ad esempio permessi, ruoli). Applica il principio del privilegio minimo a ogni endpoint.
Subject (sub)
L’ID stabile dell’utente o del client. Usalo per associare risorse e audit.
Replay e revoca (opzionale ma prudente)
Per endpoint sensibili, controlla una denylist temporanea di valori jti oppure valida uno stato di sessione attivo. Utile dopo logout o sospetto di compromissione.
Poiché i bearer token sono “chiunque li possieda può usarli”, vanno trattati come le chiavi di casa. Se qualcuno ti ruba la chiave, può entrare fino a quando non cambi la serratura.
I rischi più comuni includono:
Alcune brecce reali si sono verificate quando sviluppatori hanno accidentalmente pubblicato bearer token su repository GitHub pubblici. Gli attaccanti possono trovare questi token e sfruttarli subito per accessi non autorizzati.
Per utilizzare i bearer token in sicurezza, è importante seguire le best practice. Vediamole con degli esempi:
Utilizza sempre HTTPS
Immagina di inviare un token su HTTP normale in un bar con Wi-Fi pubblico. Chiunque stia spiando la rete può copiare il token e accedere come te.
Usa access token di breve durata
La maggior parte delle piattaforme genera token che scadono entro un’ora. Per esempio, i token OAuth di Google durano solitamente un’ora prima di dover essere rinnovati.
Gestisci con cura i refresh token
Un refresh token può richiedere nuovi access token senza che l’utente debba eseguire di nuovo il login. Ma va memorizzato in modo sicuro (per esempio in un database criptato lato server), non nell’archivio lato client.
Limita lo scope del token ai permessi minimi
Se la tua app deve solo leggere il calendario, non richiedere write:calendar. Così si riducono i danni in caso di compromissione del token.
Revoca i token quando necessario
Molte app SaaS permettono agli utenti di vedere le sessioni attive e revocarle. GitHub, ad esempio, consente di revocare i personal access token in ogni momento.
Monitora l’utilizzo
Registrare l’uso dei token può rivelare attività sospette. Se lo stesso token viene usato improvvisamente da Londra e New York a distanza di minuti, è un segnale d’allarme.
È utile mettere a confronto i bearer token con altri approcci diffusi:
Cookie e Sessioni
I siti tradizionali usano sessioni memorizzate lato server identificate da un cookie. Funziona bene per app browser, ma è meno efficiente per API o app mobile. Ad esempio, l’accesso a Facebook da desktop usa principalmente i cookie, mentre le API mobile usano token.
API Key
Un’API key è una stringa statica che autentica l’applicazione, non l’utente. Un’app meteo potrebbe usare una API key per recuperare dati, ma la chiave non indica quale utente ha fatto la richiesta. I bearer token possono includere dati specifici per utente, rendendoli più versatili.
Mutual TLS (mTLS)
Alcuni sistemi ad alta sicurezza usano certificati sia sul client che sul server. È più sicuro, ma difficile da implementare su larga scala. Per la maggior parte delle piattaforme SaaS, i bearer token rappresentano il giusto compromesso tra usabilità e sicurezza.