JWT: JSON WEB TOKEN: un nuovo modo per autenticare le nostre sessioni in modo sicuro e scalabile
Json Web Token (JWT) è uno standard, abbastanza recente, uscito all’inizio del 2015 che consente al server di scrivere in un messaggio (payload) chi è l’utente loggato (e altre info di contorno), incapsulare questo messaggio all’interno di un token e darlo al client che lo utilizzerà da ora in poi per le successive chiamate al server, informandolo così di chi sta effettuando la chiamata. Questo consentirà al server di avere già le informazioni di autenticazione direttamente nel token stesso, evitando così dover passare dal database o di usare le sessioni per memorizzare le informazioni sull’autenticazione.
PERCHE’ USARE JWT? Facciamo un passo indietro
Quando facciamo una login, siamo abituati a creare una sessione tra il server e il client e a memorizzare user_id all’interno della sessione, al fine di recuperare le informazioni di autenticazione nelle successive chiamate. Qui già sorge un piccolo problema: cosa succede se utilizziamo più server per bilanciare il carico del nostro sito? Se abbiamo creato la sessione quando eravamo sul server A e successivamente il bilanciatore di risorse ci porta sul server B la sessione sul server A che aveva i nostri dati di autenticazione la perdiamo (in realtà per avere sessioni condivise su più server le sessioni non si memorizzano più localmente ma si tendono a memorizzarle all’interno di uno spazio condiviso…su un database no-sql ad esempio).
Se invece stiamo progettando un sistema api vorremmo utilizzare un token per far riferimento a una particolare sessione di autenticazione. Quindi quando viene effettuata una chiamata all’api login, effettuo lato server un autenticazione, creo il token, lo memorizzo nel database associandolo ad utente (magari con un timestamp di scadenza) e lo restituisco al client. Il client passerà questo token nelle successive chiamate, il server accede al db e verifica a quale utente è associato quel token. OK già va un po’ meglio…in realtà è peggio…stiamo creando un collo di bottiglia tra i vari server e il DB poichè ad ogni richiesta api partirà una query al database per capire a quale utente è associato quel token, oltre che a creare un problema di sicurezza (il database potrebbe essere attaccato da qualche utente malintenzionato e recuperare tutti i nostri token di sessione)
Ma ecco così che entra in gioco Json Web Token.
L’idea che c’è alla base è che dopo l’autenticazione, il server prepara un token all’interno del quale racchiude un payload in cui viene dichiarato in maniera esplicita chi è l’utente loggato. Dentro il token, oltre il payload viene inserita la firma dal server(costituto dal payload stesso criptato con la sua chiave segreta in codifica hash 256). Il client riceve il token e se vuole sarà libero di leggere il payload contenuto ma non potrà modificarlo poichè se lo facesse il token sarà invalidato dal server. Il client dovrà comunicare al server il token ricevuto per tutte le successive chiamate in cui è richiesta l’autenticazione. Il server riceverà il token ed estrapolerà il payload ma prima si assicurerà che il token sia stato firmato e autentificato con la sua chiave privata. Poichè il token contiene il payload con tutte le informazioni necessarie all’autenticazione (es. iduser), il server potrà evitare di passare ogni volta dal database per verificare a quale utente corrisponde quel token (ottimo per la scalabilità). Entriamo un po’ più nel pratico.
COME VIENE COSTRUITO IL Json Web Token?
Potete fare subito delle prove e vedere come viene costruito usando questo tool: http://jwt.io/#debugger
Il token è costituito da 3 parti:
HEADER
