Token opachi vs JWT

In Logto, come piattaforma CIAM completa basata su OIDC, i token di autorizzazione svolgono un ruolo cruciale nella sicurezza delle interazioni degli utenti e nella gestione dell'accesso alle risorse. Tra i vari tipi di token utilizzati per l'autorizzazione, i token opachi e i JWT (JSON Web Token) sono i più importanti.

Abbiamo ricevuto diverse domande dalla nostra comunità, come: Qual è la differenza tra un token opaco e un JWT? Perché non riesco a decodificare il token di accesso che ho ricevuto, e perché la lunghezza del token sembra corta? Questo post sul blog mira a chiarire questi concetti e aiutarti a comprendere le distinzioni tra token opachi e JWT, i loro casi d'uso, e perché potresti incontrare comportamenti diversi lavorando con essi.

Cos'è un token opaco?#

Un token opaco è un tipo di token di accesso che, come suggerisce il nome, è opaco o non trasparente per il cliente o qualsiasi parte esterna. Questo significa che il token stesso non contiene nessuna informazione leggibile sull'utente o sull'autorizzazione concessa.

Quando ricevi un token opaco, spesso appare come una stringa di caratteri apparentemente casuali, e tentare di decodificarlo non fornirà dati significativi.

Ecco un esempio di un token opaco:

Dato che il contenuto effettivo del token è conosciuto solo dal server di autorizzazione che lo ha emesso, per validare un token opaco, il cliente deve restituirlo al server, che poi verifica la sua autenticità e determina i permessi associati. Questo approccio garantisce che le informazioni sensibili rimangano nascoste, fornendo un ulteriore strato di sicurezza, ma richiede anche ulteriori comunicazioni al server per validare il token.

Pro:

• sicuro: I token opachi non espongono alcuna informazione sensibile al cliente. Il contenuto del token è conosciuto solo dal server di autorizzazione.
• revocabile: Poiché il token è memorizzato sul server, e l'unico modo per validarlo è tramite l'endpoint di introspezione sul server di autorizzazione, il server può facilmente revocare il token se necessario e prevenire l'accesso non autorizzato.
• dimensioni ridotte: I token opachi sono tipicamente più corti dei JWT, il che può essere utile per considerazioni di performance e archiviazione.

Contro:

• con stato: I token opachi richiedono al server di autorizzazione di mantenere uno stato per validare il token, il che può introdurre ulteriore complessità e overhead.
• prestazioni: La necessità di ulteriore comunicazione al server per validare il token può influire sulle prestazioni, specialmente in scenari ad alto traffico.

Cos'è un JWT?#

In contrasto con i token opachi, un JWT (JSON Web Token) è un token auto-contenuto e senza stato che porta informazioni in un formato strutturato e leggibile.

Un JWT è composto da tre parti: un header, un payload, e una firma, ciascuno codificato in Base64URL.

Ecco un esempio di un JWT:

• L'header contiene informazioni sul tipo di token e sull'algoritmo usato per la firma. Ad esempio, {"alg": "HS256", "typ": "JWT"}.
• La sezione payload contiene i claim—pezzi di informazione sull'utente o sull'autorizzazione—come l'ID utente, il tempo di scadenza, e gli scope. Poiché questi dati sono codificati ma non criptati, chiunque abbia il token può decodificarlo per vedere i claim, anche se non può alterarli senza invalidare la firma. Basato sulla specifica e sulla configurazione del server di autorizzazione, vari claim possono essere inclusi nel payload. Questo conferisce al token la sua natura auto-contenuta. Ad esempio, {"sub": "1234567890", "name": "John Doe", "iat": 1516239022}.
• La firma è generata combinando l'header, il payload, e una chiave segreta utilizzando l'algoritmo specificato. Questa firma è usata per verificare l'integrità del token e assicurarsi che non sia stato manomesso.

I JWT sono comunemente usati perché possono essere verificati localmente dal cliente o da qualsiasi servizio, senza bisogno di interagire con il server di autorizzazione. Questo rende i JWT particolarmente efficienti per sistemi distribuiti, dove più servizi potrebbero dover verificare l'autenticità del token indipendentemente.

Tuttavia, questa comodità comporta anche la responsabilità di assicurarsi che i claim del token non siano eccessivamente esposti, poiché sono visibili a chiunque abbia accesso al token. Inoltre, i JWT sono tipicamente di breve durata, e il tempo di scadenza è incluso nei claim del token per garantire che il token non sia valido indefinitamente.

Pro:

• senza stato: I JWT sono auto-contenuti e non richiedono uno stato lato server per essere validati.
• compatibilità tra servizi: I JWT possono essere facilmente condivisi e verificati tra diversi servizi, rendendoli ideali per sistemi distribuiti.
• estensibile: Il payload di un JWT può contenere claim personalizzati, permettendo un'autorizzazione flessibile e una condivisione delle informazioni.
• standard: I token JWT seguono uno standard ben definito (RFC 7519), rendendoli ampiamente supportati e interoperabili.

Contro:

• esposizione: I claim in un JWT sono visibili a chiunque abbia accesso al token, quindi le informazioni sensibili non dovrebbero essere incluse nel payload.
• grandezza: I JWT possono essere più grandi dei token opachi a causa delle informazioni aggiuntive che contengono, il che può influire sulle prestazioni e sull'archiviazione. I claim nei token JWT dovrebbero essere mantenuti al minimo per ridurre la dimensione del token.
• complessità di revoca: Poiché i JWT sono senza stato, sono tipicamente validi per un breve periodo di tempo, e non esiste un meccanismo incorporato per revocare i token prima che scadano, il che significa che un token compromesso può rimanere valido fino alla scadenza.

Validazione token di accesso opachi#

Un token di accesso opaco viene validato inviandolo di nuovo al server di autorizzazione per la verifica. Il server di autorizzazione mantiene lo stato dei token emessi e può determinare la validità del token in base al suo archivio interno.

1. Il cliente richiede un token di accesso al server di autorizzazione.
2. Il server di autorizzazione emette un token opaco.
3. Il cliente invia la richiesta di accesso alla risorsa con il token opaco nell'intestazione.
4. Il fornitore di risorse invia una richiesta di introspezione del token al server di autorizzazione per validare il token.
5. Il server di autorizzazione risponde con le informazioni sul token.

Validazione token di accesso JWT (offline)#

Un token di accesso JWT può essere validato offline dal cliente o da qualsiasi servizio che abbia accesso alla chiave pubblica del token.

0. Il fornitore di risorse pre-recupera la chiave pubblica del server di autorizzazione dall'endpoint di discovery OIDC. La chiave pubblica è utilizzata per verificare la firma del token e assicurare la sua integrità.
1. Il cliente richiede un token di accesso al server di autorizzazione.
2. Il server di autorizzazione emette un token JWT.
3. Il cliente invia la richiesta di accesso alla risorsa con il token JWT nell'intestazione.
4. Il fornitore di risorse decodifica e valida il token JWT usando la chiave pubblica ottenuta dal server di autorizzazione.
5. Il fornitore di risorse concede l'accesso basato sulla validità del token.

Casi d'uso in OIDC#

Nel contesto di OIDC (OpenID Connect), i token opachi e i JWT servono scopi differenti e vengono utilizzati in scenari distinti.

Token opachi#

1. Recupero profilo utente:

Per impostazione predefinita, quando un cliente richiede un token di accesso senza specificare una risorsa e include lo scope openid, il server di autorizzazione emette un token di accesso opaco. Questo token è utilizzato principalmente per recuperare informazioni del profilo utente dall'endpoint /oidc/userinfo OIDC. Al ricevimento di una richiesta con il token di accesso opaco, il server di autorizzazione verifica il suo archivio interno per recuperare le informazioni di autorizzazione associate e verifica la validità del token prima di rispondere con i dettagli del profilo utente.

2. Scambio del token di aggiornamento:

I token di aggiornamento sono progettati per essere scambiati solo tra il cliente e il server di autorizzazione, senza bisogno di essere condivisi con i fornitori di risorse. Pertanto, i token di aggiornamento sono tipicamente emessi come token opachi. Quando il token di accesso corrente scade, il cliente può usare il token di aggiornamento opaco per ottenere un nuovo token di accesso, assicurando un accesso continuo senza ri-autenticare l'utente.

JWT#

1. Token ID:

In OIDC, il token ID è un JWT che contiene informazioni sull'utente ed è usato per autenticare l'utente. Tipicamente emesso insieme al token di accesso, il token ID permette al cliente di verificare l'identità dell'utente. Ad esempio:

Il cliente può validare il token ID per garantire l'identità dell'utente ed estrarre informazioni sull'utente per personalizzazione o scopi di autorizzazione. Il token ID è per un solo uso e non dovrebbe essere usato per l'autorizzazione delle risorse API.

2. Accesso alle risorse API:

Quando un cliente richiede un token di accesso con un indicatore di risorsa specifico, il server di autorizzazione emette un token di accesso JWT destinato ad accedere a quella risorsa. Il JWT contiene claim che il fornitore di risorse può usare per autorizzare l'accesso del cliente. Ad esempio:

Il fornitore di risorse può validare la richiesta controllando i claim:

• iss: Conferma che il token è stato emesso da un server di autorizzazione fidato.
• sub: Identifica l'utente associato al token.
• aud: Assicura che il token sia destinato alla specifica risorsa.
• scope: Verifica i permessi concessi all'utente.

Conclusione#

In sintesi, i token opachi e i JWT servono scopi diversi nei sistemi basati su OIDC, con i token opachi che forniscono un approccio sicuro e con stato all'autorizzazione e i JWT che offrono un'alternativa auto-contenuta e senza stato. Comprendere le distinzioni tra questi tipi di token e i loro casi d'uso è essenziale per progettare meccanismi di autenticazione e autorizzazione sicuri ed efficienti nelle tue applicazioni.

Scopri di più sulle funzionalità dei token di accesso in Logto:

• Usa RBAC per proteggere la tua API
• Token di accesso dell'organizzazione
• Claim JWT personalizzati