Cosa sono i bearer token?

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.

Cos’è un bearer token?#

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.”

Come funzionano i bearer token nella pratica#

Il flusso dei bearer token può essere suddiviso in alcuni passaggi:

1. L’utente effettua l’accesso

   Supponiamo che tu acceda ad un’app bancaria con username e password.

2. Il provider d’identità rilascia un token

   Dopo la verifica, il server di autenticazione restituisce un bearer token. Questo potrebbe apparire così:

3. Il client usa il token

   Ogni volta che tocchi “Controlla saldo” o “Trasferisci denaro”, l’app include il token nella richiesta HTTP:

4. 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).

5. 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.

Perché i bearer token sono diventati famosi#

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.

Cosa contiene un bearer token?#

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.

Bearer token vs access token: qual è la differenza?#

È facile confondere bearer token e access token, perché spesso appaiono insieme. In realtà, sono correlati ma non identici.

Access token: Il “permesso”#

Un access token è una credenziale che rappresenta l’autorizzazione di un utente ad accedere a una risorsa. Porta informazioni come:

• Chi è l’utente (il suo ID)
• Cosa è autorizzato a fare (scope/autorizzazioni)
• Quando il token scade

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.”

Bearer token: Il “formato di consegna”#

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:

• Tutti i bearer token sono access token.
• Ma non tutti gli access token devono essere bearer token.

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.

Esempio pratico#

• Access token (generico): Può essere un dato firmato, talvolta richiede che il client possieda anche una chiave privata.
• Bearer token (specifico): La maggior parte delle implementazioni OAuth 2.0 oggi rilasciano access token in formato bearer. Ad esempio, Google OAuth restituisce un access token che usi nell’header Authorization: Bearer <token>.

Questo significa che quando nei tutorial OAuth si parla di “access token”, quasi sempre si intende un bearer token, salvo diversa indicazione.

Confronto con altri tipi di token#

Per chiarire meglio, ecco un confronto tra bearer token e altri tipi comuni di token:

• Refresh token: Usato per ottenere un nuovo access token quando quello vecchio scade. I refresh token di solito non sono bearer token, perché vengono scambiati in modo sicuro con il server di autorizzazione e non vengono inviati direttamente alle API.
• ID token: Usato per l’autenticazione, non per l’autorizzazione. Include informazioni identificative sull’utente (come email, nome o ID utente). A seconda del sistema, anche un ID token può essere un bearer token, ma il suo scopo è diverso da quello di un access token.
• API key: Una forma più semplice di credenziale che identifica l’applicazione chiamante. In molti casi, le API key funzionano come i bearer token, dato che chiunque abbia la chiave può chiamare l’API.

Bearer token e access token non sono concetti opposti — sono collegati per ambito:

• La maggior parte degli access token sono bearer token.
• Un bearer token descrive come viene usato il token (voucher per l’accesso).
• Nell’uso quotidiano, i termini “access token” e “bearer token” vengono spesso usati in modo intercambiabile, anche se tecnicamente mettono in evidenza aspetti diversi.

Come validare un access token JWT (Bearer token)#

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.

L’idea di base#

1. Analizza il token.
2. Verifica la firma con la chiave pubblica dell’emittente.
3. Controlla le claim standard come issuer, audience, scadenza, not-before.
4. Applica le regole dell’app come scope, ruoli e tipo di token.
5. Opzionalmente consulta le denylist o lo stato della sessione per azioni ad alto rischio.

Checklist di validazione (JWT)#

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.

Rischi di sicurezza dei bearer token#

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:

• Furto del token – Se un hacker accede alla localStorage del browser dove è salvato il token, può impersonare l’utente. Nel 2018, ad esempio, alcune estensioni browser sono state scoperte a sottrarre token dalla localStorage e venderli.
• Replay attack – Un attaccante che intercetta un token può riutilizzarlo finché non scade. Senza HTTPS, è sorprendentemente facile.
• Token di lunga durata – Se un token è valido per settimane o mesi, aumenta la finestra di attacco per i malintenzionati.

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.

Best practice per l’utilizzo dei bearer token#

Per utilizzare i bearer token in sicurezza, è importante seguire le best practice. Vediamole con degli esempi:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

Bearer token vs altri metodi di autenticazione#

È 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.

Riepilogo#

• I bearer token sono semplici ma potenti: chiunque abbia il token può accedere alla risorsa.
• Sono ampiamente usati nei flussi OAuth 2.0 e OIDC, specialmente per API e app mobile.
• La sicurezza dipende da come li gestisci: durata breve, scope, HTTPS e revoca sono cruciali.
• Non sono sempre la scelta migliore, ma nella maggior parte dei casi SaaS e API rappresentano l’equilibrio ideale tra sicurezza e praticità.