JWT vs OAuth: differenze chiave, come funzionano insieme e migliori pratiche

Se sei nuovo all'autenticazione e stai costruendo un'app che gestisce login, pagamenti o dati utente, probabilmente ti sei imbattuto nei termini JWT e OAuth. Potrebbero sembrare argomenti complessi, "solo backend", ma non sono solo per gli ingegneri della sicurezza.

Con le API, integrazioni di terze parti e nuove tecnologie come AI, MCP e sistemi basati su agenti, questi due giocano un ruolo diretto nell'usabilità, sicurezza e crescita del tuo prodotto. Comprendere le basi ti permette di:

• Progettare funzionalità sicure sin dall'inizio
• Comunicare efficacemente con il tuo team di ingegneri
• Prendere decisioni migliori sul prodotto riguardo autenticazione e flussi utente
• Evitare costosi errori di sicurezza che minano la fiducia degli utenti

Ad esempio, nell'ultimo MCP spec, il sistema di autorizzazione si basa su standard consolidati:

• OAuth 2.1 IETF Draft (draft-ietf-oauth-v2-1-13)
• OAuth 2.0 Authorization Server Metadata (RFC8414)
• OAuth 2.0 Dynamic Client Registration Protocol (RFC7591)
• OAuth 2.0 Protected Resource Metadata (RFC9728)

Perché è importante#

Anche se non scriverai mai codice backend:

• Gli sviluppatori imparano come proteggere le API, gestire le sessioni e integrare servizi di terze parti.
• I product manager acquisiscono il vocabolario per discutere flussi di login, integrazioni e conformità con team e partner.
• I founder e i team nelle prime fasi evitano di costruire sistemi di login fragili che si rompono con le integrazioni o ti espongono a violazioni.

JWT vs OAuth: i due concetti fondamentali#

JWT (JSON Web Token) e OAuth (Open Authorization) sono spesso usati insieme, ma hanno scopi diversi.

Pensala così:

• OAuth è come dai le chiavi a qualcuno, ma solo delle stanze in cui possono entrare.
• JWT è la carta d'identità che portano con sé, prova di chi sono e cosa possono fare.

Nella prossima sezione, li analizzeremo fianco a fianco così potrai vedere chiaramente le differenze e come si completano a vicenda.

Cos'è OAuth 2.0?#

OAuth 2.0 è un framework di autorizzazione ampiamente adottato che permette a un'applicazione (il client) di accedere alle risorse di un utente con permessi limitati, senza dover condividere le credenziali dell'utente (ad esempio le password).

Ruoli principali in OAuth#

• Client: L'applicazione che richiede l'accesso.
• Resource owner: Di solito l'utente, che concede il permesso.
• Authorization server: Rilascia i token di accesso dopo l'autorizzazione.
• Resource server: Ospita le risorse protette e valida i token

Tipologie comuni di grant (Flussi) OAuth#

• Authorization Code Grant: Il più sicuro e raccomandato, soprattutto con PKCE per browser, SPA e app mobile.
• Implicit Grant: Ora sconsigliato in OAuth 2.1 per motivi di sicurezza.
• Resource Owner Password Credentials (ROPC): Scambia direttamente username e password per i token; meno sicuro.
• Client Credentials Grant: Per comunicazione server-to-server o machine-to-machine.
• Device Flow: Per dispositivi senza tastiera (es. smart TV), dove l'utente autorizza da un secondo dispositivo.

Cos'è JWT (JSON Web Token)?#

Un JWT è uno standard aperto (RFC 7519) per trasmettere in modo sicuro delle asserzioni tra due parti in modo compatto e sicuro per gli URL.

Struttura di un JWT#

Un JWT è composto da tre parti codificate base64url, separate da punti (.):

1. Header: Specifica l'algoritmo (es. HS256, RS256) e il tipo di token (JWT).
2. Payload: Contiene le asserzioni (claims), ad esempio:
   • iss (issuer)
   • sub (subject, es. ID utente)
   • aud (audience)
   • exp (expiration time)
   • Asserzioni custom se necessario
3. Signature – Verifica che il token non sia stato manomesso.

Esempio:

Un esempio di JWT#

Ecco un esempio di tipico JWT nella sua forma codificata, insieme alla sua struttura decodificata così puoi vedere cosa rappresenta ciascuna parte.

JWT codificato (Base64URL)

È composto da tre parti separate da punti: header.payload.signature

Struttura decodificata

• Header

• Payload

Il payload contiene le asserzioni

• Signature

La firma garantisce che il token non sia stato manomesso.

Caratteristiche chiave#

• Self-contained: Tutte le informazioni necessarie sono all'interno del token.
• Stateless: Non è necessario uno storage di sessione sul server.
• Firmato: (e opzionalmente cifrato) per garantire l'autenticità.

JWT vs OAuth: differenze fondamentali#

In breve:

• JWT è il contenitore: come un passaporto con dettagli di identità.
• OAuth è il sistema: come il controllo immigrazione, che decide chi ottiene il passaporto e cosa può fare.

Quando usare solo JWT#

Usa solo JWT quando:

• Autenticazione in un unico sistema dove la tua app emette e verifica i token senza coinvolgere un identity provider esterno.
• Session management stateless per validare l'identità dell'utente senza salvare dati di sessione sul server.
• Autenticazione semplice delle API per API interne che devono solo verificare diritti basilari senza flussi di consenso complessi.
• Validazione ad alte prestazioni così i resource server possono validare i token localmente senza contattare un auth server.

Esempio:

Una SPA e API backend che possiedi. L'API emette un JWT con le asserzioni sub (user ID), ruolo e exp (scadenza).

Quando usare solo OAuth#

Usa OAuth senza JWT quando:

• Non hai bisogno di token self-contained, e i token opachi che richiedono lookup vanno bene.
• Vuoi che il resource server controlli sempre con l'authorization server prima di concedere accesso.
• Sei in un ambiente legacy o regolamentato dove JWT non è adatto.
• L'obiettivo è l'autorizzazione delegata per concedere in modo sicuro accesso limitato ad app di terze parti.

Esempio:

Un'API che rilascia access token opachi e valida ogni richiesta interrogando l'authorization server.

Quando usare sia JWT che OAuth#

Usali insieme quando:

• Hai più servizi o API e vuoi OAuth per la sicurezza del flusso e JWT per token verificabili per tutti i servizi.
• Offri login di terze parti come "Accedi con Google" dove OAuth gestisce il consenso e JWT trasporta l'access token o l'ID token.
• Gestisci un'architettura a microservizi dove ogni servizio può convalidare localmente i JWT.
• Hai bisogno di scalabilità grazie al modello di delega di OAuth e la verifica stateless di JWT.

Esempio:

La tua app permette agli utenti di accedere con Google. OAuth gestisce il processo di autorizzazione, Google rilascia un JWT access token e le tue API lo verificano localmente prima di restituire i dati.

Come funzionano insieme JWT e OAuth#

Negli scenari moderni di autenticazione/autorizzazione:

1. OAuth gestisce il flusso per concedere l'accesso.
2. L'Authorization Server rilascia un access token: spesso un JWT.
3. Il JWT viene inviato con le richieste API per provare identità e permessi.

Token speciali in OAuth#

• ID token: Usato in OpenID Connect per provare l'identità dell'utente; sempre un JWT.
• Access token: Può essere un JWT o un token opaco.

Migliori pratiche per JWT e OAuth#

• Usa HTTPS per proteggere i token in transito.
• Imposta scadenze brevi per i JWT; usa i refresh token per sessioni più lunghe.
  • https://auth.wiki/offline-access.
• Valida la firma prima di fidarti di qualsiasi claim.
• Controlla il claim aud per assicurarti che il token sia destinato alla tua app.
• Evita di salvare i token in localStorage se c'è rischio XSS; preferisci cookie sicuri.

Considerazioni finali#

• OAuth 2.0 definisce come ottenere e usare i token.
• JWT definisce come è fatto il token e come trasporta le informazioni.
• Sono complementari, non intercambiabili.

La maggior parte delle API moderne usa OAuth per i flussi di autorizzazione e JWT per la rappresentazione del token. Comprenderli ti aiuterà a progettare sistemi di autenticazione sicuri e scalabili.