Introduzione
Autenticazione basata su token è prominente ovunque sul web al giorno d’oggi. Con la maggior parte delle aziende web che utilizzano un’API, i token sono il modo migliore per gestire l’autenticazione per più utenti.
Ci sono alcuni fattori molto importanti quando si sceglie l’autenticazione basata su token per la propria applicazione. I motivi principali per i token sono:
- Server stateless e scalabili
- Mobile application ready
- Passa l’autenticazione ad altre applicazioni
- Sicurezza extra
Chi utilizza l’autenticazione basata su token?
Qualsiasi API principale o applicazione Web che hai incontrato ha probabilmente utilizzato token. Applicazioni come Facebook, Twitter, Google+, GitHub e tanti altri token di utilizzo.
Diamo un’occhiata esattamente come funziona.
Perché i token sono arrivati
Prima di poter vedere come funziona l’autenticazione basata su token e i suoi vantaggi, dobbiamo esaminare il modo in cui l’autenticazione è stata eseguita in passato.
Autenticazione basata su server (il metodo tradizionale)
Poiché il protocollo HTTP è stateless, ciò significa che se autentichiamo un utente con un nome utente e una password, alla richiesta successiva, la nostra applicazione non saprà chi siamo. Dovremmo autenticarci di nuovo.
Il modo tradizionale per far sì che le nostre applicazioni ricordino chi siamo è quello di memorizzare le informazioni di accesso dell’utente sul server. Questo può essere fatto in diversi modi sulla sessione, di solito in memoria o memorizzati sul disco.
Poiché il web, le applicazioni e l’ascesa dell’applicazione mobile sono avvenuti, questo metodo di autenticazione ha mostrato problemi, specialmente nella scalabilità.
I problemi con l’autenticazione basata su server
Alcuni problemi importanti sono sorti con questo metodo di autenticazione.
- Sessioni: Ogni volta che un utente viene autenticato, il server dovrà creare un record da qualche parte sul nostro server. Questo di solito viene fatto in memoria e quando ci sono molti utenti che si autenticano, il sovraccarico sul server aumenta.
- Scalabilità: poiché le sessioni sono memorizzate in memoria, ciò fornisce problemi di scalabilità. Poiché i nostri fornitori di cloud iniziano a replicare i server per gestire il carico delle applicazioni, avere informazioni vitali nella memoria della sessione limiterà la nostra capacità di scalare.
- CORS: Poiché vogliamo espandere la nostra applicazione per consentire ai nostri dati di essere utilizzati su più dispositivi mobili, dobbiamo preoccuparci della condivisione delle risorse cross-origin (CORS). Quando si utilizzano chiamate AJAX per afferrare risorse da un altro dominio (mobile al nostro server API), potremmo incorrere in problemi con le richieste proibite.
- CSRF: Avremo anche protezione contro la contraffazione di richieste cross-site (CSRF). Gli utenti sono suscettibili agli attacchi CSRF poiché possono già essere autenticati con un sito bancario e questo potrebbe essere sfruttato quando si visitano altri siti.
Con questi problemi, essendo la scalabilità la principale, aveva senso provare un approccio diverso.
Come funziona basato su token
L’autenticazione basata su token è stateless. Non memorizziamo alcuna informazione sul nostro utente sul server o in una sessione.
Questo concetto da solo si occupa di molti dei problemi con la necessità di memorizzare informazioni sul server.
Nessuna informazione di sessione significa che l’applicazione può scalare e aggiungere più macchine, se necessario, senza preoccuparsi di dove un utente è connesso.
anche se questa implementazione può variare, l’essenza di esso è come indicato di seguito:
- Utente richiede l’Accesso con nome utente / Password
- Applicazione convalida le credenziali
- Applicazione fornisce un firmato token per il client
- Client negozi token e lo invia insieme a ogni richiesta
- Server verifica il token e risponde con dati
Ogni singola richiesta richiede il token. Questo token deve essere inviato nell’intestazione HTTP in modo da mantenere l’idea delle richieste HTTP stateless. Dovremo anche impostare il nostro server per accettare richieste da tutti i domini usando Access-Control-Allow-Origin: *. La cosa interessante della designazione di * nell’intestazione ACAO è che non consente alle richieste di fornire credenziali come l’autenticazione HTTP, i certificati SSL lato client o i cookie.
Una volta che abbiamo autenticato con le nostre informazioni e abbiamo il nostro token, siamo in grado di fare molte cose con questo token.
Potremmo persino creare un token basato su autorizzazioni e passarlo a un’applicazione di terze parti (ad esempio una nuova app mobile che vogliamo usare), e saranno in grado di avere accesso ai nostri dati-ma solo le informazioni che abbiamo permesso con quel token specifico.
I vantaggi dei token
Stateless e scalabili
I token vengono memorizzati sul lato client. Completamente apolide e pronto per essere ridimensionato. I nostri bilanciatori di carico sono in grado di passare un utente a uno qualsiasi dei nostri server poiché non ci sono informazioni sullo stato o sulla sessione da nessuna parte.
Se dovessimo mantenere le informazioni di sessione su un utente che ha effettuato l’accesso, ciò richiederebbe di continuare a inviare quell’utente allo stesso server in cui ha effettuato l’accesso (chiamato affinità di sessione).
Questo porta problemi dal momento che alcuni utenti sarebbero costretti allo stesso server e questo potrebbe causare un po ‘ di traffico pesante.
Non preoccuparti però! Questi problemi sono spariti con i token poiché il token stesso contiene i dati per quell’utente.
Sicurezza
Il token, non un cookie, viene inviato ad ogni richiesta e poiché non viene inviato alcun cookie, questo aiuta a prevenire gli attacchi CSRF. Anche se la tua implementazione specifica memorizza il token all’interno di un cookie sul lato client, il cookie è semplicemente un meccanismo di archiviazione invece di uno di autenticazione. Non ci sono informazioni basate sulla sessione da manipolare poiché non abbiamo una sessione!
Il token scade anche dopo un determinato periodo di tempo, quindi a un utente verrà richiesto di accedere nuovamente. Questo ci aiuta a rimanere al sicuro. Esiste anche il concetto di revoca del token che ci consente di invalidare un token specifico e persino un gruppo di token basati sulla stessa concessione di autorizzazione.
Estensibilità (Amico di un amico e permessi)
I token ci permetteranno di creare applicazioni che condividono le autorizzazioni con un altro. Ad esempio, abbiamo collegato account sociali casuali ai nostri principali come Facebook o Twitter.
Quando accediamo a Twitter tramite un servizio (diciamo Buffer), stiamo permettendo a Buffer di pubblicare sul nostro flusso Twitter.
Utilizzando i token, questo è il modo in cui forniamo autorizzazioni selettive alle applicazioni di terze parti. Potremmo persino creare la nostra API e distribuire token di autorizzazione speciali se i nostri utenti volessero dare accesso ai loro dati a un’altra applicazione.
Più piattaforme e domini
Abbiamo parlato un po ‘ di CORS in precedenza. Quando la nostra applicazione e il servizio si espande, avremo bisogno di fornire l’accesso a tutti i tipi di dispositivi e applicazioni (dal momento che la nostra applicazione sarà sicuramente diventare popolare!).
Avendo la nostra API solo servire i dati, possiamo anche fare la scelta di progettazione per servire le risorse da un CDN. Questo elimina i problemi che CORS porta in primo piano dopo aver impostato una configurazione di intestazione rapida per la nostra applicazione.
Access-Control-Allow-Origin: *I nostri dati e le nostre risorse sono ora disponibili per le richieste di qualsiasi dominio purché un utente disponga di un token valido.
Basato su standard
Quando si crea il token, sono disponibili alcune opzioni. Ci immergeremo di più in questo argomento quando proteggeremo un’API in un articolo di follow-up, ma lo standard da utilizzare sarebbero i token Web JSON.
Questo pratico debugger e grafico libreria mostra il supporto per i token Web JSON. Si può vedere che ha una grande quantità di supporto in una varietà di lingue. Ciò significa che potresti effettivamente cambiare il tuo meccanismo di autenticazione se scegli di farlo in futuro!
Conclusione
Questo era solo uno sguardo al come e perché dell’autenticazione basata su token. Come sempre accade nel mondo della sicurezza, c’è molto di più in ogni argomento e varia in base al caso d’uso. Abbiamo anche tuffato in alcuni argomenti sulla scalabilità che merita la propria conversazione pure.
Questa è stata una rapida panoramica di alto livello, quindi non esitate a sottolineare tutto ciò che è stato perso o qualsiasi domanda che avete in materia.
Nel nostro prossimo articolo, esamineremo l’anatomia dei token Web JSON.
Nota: Aggiunta di informazioni sull’intestazione ACAO e chiarimenti CSRF (grazie a Emily Stark per le informazioni sull’articolo)