Token Auth VS Serve Based Auth

Nelle autenticazioni SBA il server si occupa di mantenere una sessione (vedi PHP Session) e salvare al suo interno le informazioni necessarie per poterla collegare ad un'utenza, successivamente invierà al client un identificativo della session che esso dovrà aver cura di memorizzare e presentare per poter essere associato a una data sessione, per ogni richiesta effettuata.

Problemi legati alla Server Based Authentication:

• Overhead: Per ogni utente che si collega, il server deve creare una variabile di sessione che risiede in memoria (volatile o di massa) quindi più utenti sono connessi, maggiori session risiedono nel sistema e maggiore è l'overhead.
• Scalabilità: Il fatto che le sessioni siano memorizzate in memoria, crea problemi di scalabilità^[1]. Realtà medio-grandi richiedono che venga effettuato un bilanciamento del carico per i server. Il fatto di dover mantenere in memoria i dati delle sessioni, implica l'utilizzo di macchine dedicate al compito e questo comporta, ovviamente, costi supplementari. Anche salvando le sessioni in database no-sql, ci sarebbero comunque complicazioni nella scalabilità.

Con l'aumentare dell'utenza d'internet è anche aumentato il carico di traffico generato, per ciò la tendenza è quella di muovere quanto più possibile client side, per ridurre il lavoro richiesto a i server.

Nelle autenticazioni basate su token, in corrispondenza della validazione delle credenziali di login, il server provvede a generare un token la cui validità può essere verifica dal server tramite una firma d'integrità fornita con il token e ricalcolata dal back-end. Cura del client è mantenere copia di questo token e presentarlo a ogni richiesta come autenticazione.

Vantaggi legati alle Token Based Authentication:

• Stateless: Le informazioni necessarie per collegare il token a dati contenuti in una base dati o per verificarne le autorizzazioni a compiere specifiche azioni, sono contenute nello stesso token (vantaggioso per la scalabilità e riduzione dell'overhead del server).
• SSO: Meccanismo del Single Sign On utilizzato per accedere in sistemi differenti da quello che ha generato il token, così da avere un sistema di autenticazione unificato per tutti i portali offerti.

Svantaggi:

• Revoca dei token: I punti di forza delle autenticazioni basate su token sono anche il loro tallone d'Achille. Per quanto riguarda la revoca di un token, venendo salvato lato client, il server non ha nessun controllo su di esso e perciò devono essere costruiti sistemi in grado d'invalidare la procedura di verifica del token eseguita lato server (anche se il token è di per sè valido^[2]).

Json Web Token

Json Web Token (JWT) è uno standard abbastanza recente di Token Authentication. Si basa su JSON nello standard RFC 7519 e viene utilizzato per creare token di accesso. Il token è firmato da una delle due parti con una chiave privata (normalmente dal server) così che la sua integrità possa essere verificata.

I token JWT si basano su altri due standard Json Web Signature (RFC 7515) e Json Web Encryption (RFC 7516).

Questo è un meccanismo di autenticazione stateless in quanto lo stato dell'utente non viene mai salvato nella memoria del server. Le rotte protette del server controllano la presenza di un JWT valido nell'intestazione Autorizzazione e, se è presente, l'utente può accedere alle risorse protette. Poiché i JWT sono autonomi e tutte le informazioni necessarie sono presenti al suo interno, riducendo la necessità d'interrogare il database più volte.

Struttura JWT

Il token JWT si presenta come una stringa suddivisa in tre parti, la suddivisione avviene tramite un '.', ognuna delle tre parti viene serializzata mediante una codifica encodebase64url che divide la sequenza binaria in gruppi di 6 bit creando, in pratica, quattro cifre ogni 3 caratteri.

token = base64urlEncoding(header) + '.' + base64urlEncoding(payload);
token += '.' + base64urlEncoding(signature);

Header:

• È un oggetto json che identifica quale algoritmo è stato utilizzato per generare la Signature
• alg indica quale algoritmo è in uso (i più frequenti sono HMAC,SHA-256 e RSA, ma lo standard JWA prevede 13 algoritmi)
• typ indica il tipo di token

Payload:

• È un oggetto json che contiene una serie d'informazioni chiamate claims (esistono 7 standard comunemente incluse, più tutte quelle custom che possono essere definite liberamente)

iss e exp sono standard mentre company e awesome sono custom

Signature:

• Necessaria per verificare la validità dei primi due campi (di fatti essa è generata passando base64url(header)+'.'+base64url(payload) all'algoritmo definito nell'intestazione tramite il campo alg)

A questo punto hai già molto materiale di cui prendere visone e ti consiglio di famigliarizzare con i campi più comunemente utilizzati nell'header e nel payload del token
Esempio di token completo:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6Ikpv
aG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Fine prima parte

Si conclude così l'introduzione ai token JWT, nella seconda andremo ad analizzare le vulnerabilità più basilari andando a crescere, man mano, con la complessità nei vari articoli.