JSON Web Token come elementi costitutivi per la sicurezza del cloud

La prima bozza dei JSON Web Token ha già più di 10 anni (è del dicembre 2010). La bozza iniziale afferma: "JSON Web Token (JWT) definisce un formato di token in grado di codificare le richieste trasferite tra due parti. Le attestazioni in un JWT sono codificate come oggetto JSON con firma digitale".

Nella sua ultima versione, IETF RFC 7519, è stato ampliato come segue: "JSON Web token (JWT) è un mezzo compatto e URL-safe per rappresentare le informazioni da trasferire tra due parti. Le informazioni in un JWT sono codificate come oggetto JSON utilizzato come payload di una struttura JSON Web Signature (JWS) o come testo in chiaro di una struttura JSON Web Encryption (JWE), che consente la firma digitale delle informazioni o la protezione della loro integrità con un Message Authentication Code (MAC) e/o la loro crittografia."

La nuova descrizione allude a due rappresentazioni di un JWT (spesso pronunciato "jot"), ovvero una struttura JSON Web Signature (JWS) o una struttura JSON Web Encryption (JWE). JWS è definito in RFC 7515, JWE in RFC 7516. Esistono anche altri standard di sicurezza correlati basati su JSON, tutti definiti da un gruppo di lavoro denominato JOSE: JSON Object Signing and Encryption.

OAuth 2.0 è uno standard di settore per l'autorizzazione. Senza entrare nei dettagli, offre un flusso di autorizzazione e concetti fondamentali, tra cui il cosiddetto token di accesso e il token di aggiornamento. Non è obbligatorio utilizzarli, ma al giorno d'oggi i JWT sono quelli più comunemente utilizzati. Come affermato, l'OAuth si concentra sull'autorizzazione e a volte è stato utilizzato in modo improprio anche per gestire l'identificazione. OpenID Connect aggiunge questo pezzo mancante al puzzle e introduce il token ID. Il token ID è rappresentato come JWT.

Con questa storia e alcuni standard come base, come possiamo elaborare il JWT sopra menzionato e quali informazioni contiene?

Il JWT di cui sopra è composto da tre parti, separate ciascuna da un punto ("."):

1. Intestazione: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
2. Payload: eyJzdWIiOiIxMjM0NTY3ODkwQUJDIiwibmFtZSI6IkhlbnJpayBMb2VzZXIiLCJpYXQiOjE2MTExNDA0MDAsImV4cCI6MTYxMTIzNDU2N30
3. Firma: _iVbBcypdse-9sjrxp9iOrGsXKBWrBB3mrHgBtukcfM

Sia l'intestazione che il payload sono codificati con base64url e, non tenendo conto di un possibile padding, possono essere decodificati in questo modo:

henrik@home> base64 -d <<< eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
{"alg":"HS256","typ":"JWT"}

henrik@home> base64 -d <<< eyJzdWIiOiIxMjM0NTY3ODkwQUJDIiwibmFtZSI6IkhlbnJpayBMb2VzZXIiLCJpYXQiOjE2MTExNDA0MDAsImV4cCI6MTYxMTIzNDU2N30
{"sub":"1234567890ABC","name":"Henrik Loeser","iat":1611140400,"exp":1611234567}base64: invalid input

L'intestazione contiene informazioni sull'algoritmo utilizzato, in questo caso, HS256 (HMAC SHA256). Il payload dipende dal tipo di token (accesso, refresh, ID, ecc.) ed è composto da claim. Questi e altri campi predefiniti dell'intestazione e del payload JOSE sono gestiti da IANA. Nell’esempio sopra, i campi e i claim sono subj(ect), name, issued at (iat) ed exp(iration time).

La firma viene calcolata applicando l'algoritmo dichiarato alla concatenazione di intestazione, '.' e payload e quindi base64url codifica il risultato. Successivamente, le tre parti separate da un punto compongono il JWT. I dettagli su come vengono derivate le firme sono definiti in RFC 7515.

È possibile accedere al JWT sopra indicato tramite questo debugger online su JTW.io. Per prima cosa verrà visualizzato il messaggio "Invalid Signature". È possibile risolverlo sostituendo il segreto predefinito visualizzato con !!!my-really-big-256-bit-secret!!!.

Poiché IBM Cloud fornisce molti servizi nel suo catalogo ed è un'app Internet con molti componenti propri, fa un uso intensivo dei token, inclusi i JWT. Probabilmente hai utilizzato l'interfaccia a riga di comando (CLI) di IBM Cloud e il comando ibmcloud iam oauth-tokens:

Stampa i token OAuth bearer (token di accesso) per la sessione CLI corrente, implementati come JWT. Questi token IAM vengono utilizzati per accedere ai cloud service abilitati per IAM. 

Se vuoi integrare utenti esterni nel tuo account cloud, puoi utilizzare anche i JWT. I token di identità e i relativi claim inclusi vengono scambiati con l'autenticazione per identificare l'utente. Molte soluzioni utilizzano il servizio di sicurezza IBM Cloud App ID. Aiuta ad autenticare gli utenti e proteggere le risorse. Utilizza gli standard OAuth 2.0 e OpenID Connect menzionati e quindi gestisce i token di accesso, ID e refresh.

Per costruire un chatbot, uno dei miei (e tuoi) servizi preferiti è watsonx Assistant. Se desideri proteggere le chat web (ad esempio, proteggere ulteriormente i messaggi scambiati e certificare l'origine dei messaggi), i JWT vengono in tuo soccorso.

Naturalmente, ci sono molti altri esempi di come i JWT vengono utilizzati per scambiare facilmente informazioni (di sicurezza) e quindi rafforzare la sicurezza di una soluzione cloud.

I JWT sono un mezzo semplice e autonomo per lo scambio di informazioni tra due parti. Sono una struttura di dati onnipresente, nel cloud e on-premise. Speriamo che quanto sopra sia stata un'introduzione utile per farti interessare (se non lo eri già!).

Se vuoi esaminare e sperimentare autonomamente i JWT, ti consiglio di iniziare con uno strumento online come https://jwt.io/  . Se vuoi qualcosa di più approfondito, utilizza un monitor di rete o gli strumenti di sviluppo nel tuo browser e cerca i JWT. Divertiti con i nostri tutorial su IBM Cloud, inclusi molti tutorial relativi alla sicurezza.

Se hai feedback, suggerimenti o domande su questo post, puoi contattarmi su Twitter (@data_henrik) o LinkedIn.