Autenticazione token vs. cookie

Qual è la differenza tra autenticazione token e autenticazione tramite i cookie?

Sto cercando di implementare la demo di Ember Auth Rails ma non capisco i motivi alla base dell'utilizzo dell'autenticazione token come descritto nelle FAQ di Ember Auth sulla domanda "Perché l'autenticazione token?"

Un'app Web tipica è per lo più senza stato , a causa della sua natura richiesta / risposta . Il protocollo HTTP è il miglior esempio di protocollo senza stato . Tuttavia, poiché la maggior parte delle app Web richiedono stato , al fine di mantenere lo stato , tra server e client, i cookie vengono utilizzati in modo tale che il server possa inviare ogni risposta al client. Ciò significa che la prossima richiesta fatta dal cliente includerà questo cookie e sarà quindi riconosciuta dal server. In questo modo il server può mantenere una sessione con lo stateless cliente, conoscendo lo più tutto ciò che riguarda l'applicazione dello stato , ma memorizzati nel server. In questo scenario in nessun momento il cliente è in possessostato , che non è come funziona Ember.js .

In Ember.js le cose sono diverse. Ember.js semplifica il lavoro del programmatore perché mantiene effettivamente lo stato per te, nel client, conoscendo in ogni momento il suo stato senza dover fare una richiesta al server per richiedere dati sullo stato .

Tuttavia, mantenere lo stato nel client può anche talvolta causare problemi di concorrenza che semplicemente non sono presenti in situazioni senza stato . Ember.js, tuttavia, si occupa anche di questi problemi, in particolare ember-data è stato creato tenendo presente questo aspetto. In conclusione, Ember.js è un framework progettato per client con stato .

Ember.js non funziona come una tipica app Web senza stato in cui la sessione , lo stato e i cookie corrispondenti sono gestiti quasi completamente dal server. Ember.js mantiene lo stato completamente in javascript (nella memoria del client e non nel DOM come in altri framework) e non necessita del server per gestire la sessione. Ciò comporta che Ember.js è più versatile in molte situazioni, ad esempio quando l'app è in modalità offline.

Ovviamente per motivi di sicurezza ha bisogno di un qualche tipo di token o chiave univoca da inviare al server ogni volta che viene effettuata una richiesta per essere autenticato , in questo modo il server può cercare il token di invio (che è stato inizialmente emesso dal server) e verificare se è valido prima di inviare una risposta al client.

A mio avviso, il motivo principale per cui utilizzare un token di autenticazione anziché i cookie, come indicato nelle FAQ di Ember Auth, è principalmente a causa della natura del framework Ember.js e anche perché si adatta maggiormente al paradigma dell'app Web stateful . Pertanto, il meccanismo dei cookie non è l'approccio migliore durante la creazione di un'app Ember.js.

Spero che la mia risposta dia più significato alla tua domanda.

Http è apolide. Per autorizzarti, devi "firmare" ogni singola richiesta che stai inviando al server.

Autenticazione token

• Una richiesta al server è firmata da un "token" - di solito significa impostare intestazioni http specifiche, tuttavia, possono essere inviate in qualsiasi parte della richiesta http (corpo POST, ecc.)

• Professionisti:

  • Puoi autorizzare solo le richieste che desideri autorizzare. (Cookie: anche i cookie di autorizzazione vengono inviati per ogni singola richiesta.)
  • Immune a XSRF (breve esempio di XSRF: ti invierò un link nell'email che assomiglierà <img src="http://bank.com?withdraw=1000&to=myself" />, e se hai effettuato l'accesso tramite autenticazione cookie a bank.com e bank.com non ha alcun mezzo di XSRF protezione, preleverò denaro dal tuo account semplicemente dal fatto che il tuo browser attiverà una richiesta GET autorizzata a quell'URL.) Nota che ci sono misure anti-contraffazione che puoi fare con l'autenticazione basata su cookie, ma devi implementarle.
  • I cookie sono associati a un singolo dominio. Un cookie creato sul dominio foo.com non può essere letto dal dominio bar.com, mentre è possibile inviare token a qualsiasi dominio desiderato. Ciò è particolarmente utile per le applicazioni a pagina singola che utilizzano più servizi che richiedono l'autorizzazione, quindi posso avere un'app Web sul dominio myapp.com che può inviare richieste lato client autorizzate a myservice1.com e myservice2.com.
• Contro:
  • Devi conservare il token da qualche parte; mentre i cookie sono memorizzati "out of the box". Le posizioni che vengono in mente sono localStorage (con: il token è persistente anche dopo aver chiuso la finestra del browser), sessionStorage (pro: il token viene scartato dopo aver chiuso la finestra del browser, con: l'apertura di un collegamento in una nuova scheda renderà quella scheda anonimo) e cookie (Pro: il token viene eliminato dopo aver chiuso la finestra del browser. Se si utilizza un cookie di sessione, si verrà autenticati quando si apre un collegamento in una nuova scheda e si è immuni da XSRF poiché si ignora il cookie per l'autenticazione, lo stai semplicemente usando come token storage. Con: i cookie vengono inviati per ogni singola richiesta. Se questo cookie non è contrassegnato come solo https, sei aperto all'uomo negli attacchi intermedi.)
  • È leggermente più semplice eseguire un attacco XSS contro l'autenticazione basata su token (cioè se sono in grado di eseguire uno script iniettato sul tuo sito, posso rubare il token; tuttavia, l'autenticazione basata su cookie non è neanche un punto elenco - mentre i cookie contrassegnati come Solo http non può essere letto dal client, il client può comunque effettuare richieste per conto dell'utente che includerà automaticamente il cookie di autorizzazione.)
  • Le richieste di download di un file, che dovrebbe funzionare solo per utenti autorizzati, richiedono l'utilizzo dell'API File. La stessa richiesta è pronta all'uso per l'autenticazione basata su cookie.

Autenticazione cookie

• Una richiesta al server è sempre registrata dal cookie di autorizzazione.
• Professionisti:
  • I cookie possono essere contrassegnati come "solo http" che li rende impossibili da leggere sul lato client. Questo è meglio per la protezione dagli attacchi XSS.
  • È pronto per l'uso: non è necessario implementare alcun codice sul lato client.
• Contro:
  • Legato a un singolo dominio. (Quindi se hai un'applicazione a pagina singola che fa richieste a più servizi, puoi finire per fare cose folli come un proxy inverso.)
  • Vulnerabile verso XSRF. Devi implementare misure aggiuntive per proteggere il tuo sito da falsificazioni di richieste tra siti.
  • Vengono inviati per ogni singola richiesta (anche per le richieste che non richiedono autenticazione).

Nel complesso, direi che i token ti offrono una maggiore flessibilità (poiché non sei vincolato a un singolo dominio). L'aspetto negativo è che devi fare un po 'di programmazione da solo.

• I token devono essere memorizzati da qualche parte (archiviazione locale / sessione o cookie)

• I token possono scadere come i cookie, ma hai un maggiore controllo

• L'archiviazione locale / sessione non funziona su tutti i domini, utilizza un cookie marker

• Le richieste di verifica preliminare verranno inviate su ogni richiesta CORS

• Quando è necessario eseguire lo streaming di qualcosa, utilizzare il token per ottenere una richiesta firmata

• È più facile gestire XSS che XSRF

• Il token viene inviato ad ogni richiesta, fai attenzione alle sue dimensioni

• Se si memorizzano informazioni riservate, crittografare il token

• I token Web JSON possono essere utilizzati in OAuth

• I token non sono proiettili d'argento, pensa attentamente ai casi d'uso della tua autorizzazione

http://blog.auth0.com/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/

http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/

Per i googler :

• NON mescolare lo stato con i meccanismi di trasferimento dello stato

statefulness

• Stateful = salva le informazioni di autorizzazione sul lato server, questo è il modo tradizionale
• Stateless = salva le informazioni di autorizzazione sul lato client, insieme a una firma per garantire l'integrità

MECCANISMI

• Cookie = un'intestazione speciale con un trattamento speciale (accesso, archiviazione, scadenza, sicurezza, trasferimento automatico) da parte dei browser
• Intestazioni personalizzate = ad esempio Authorization, sono solo intestazioni senza alcun trattamento speciale, il cliente deve gestire tutti gli aspetti del trasferimento
• Altro . Altri meccanismi di trasferimento possono essere utilizzati, ad esempio la stringa di query è stata una scelta per trasferire l'ID di autenticazione per un po 'ma è stata abbandonata per la sua insicurezza

CONFRONTO DI STATEFULNESS

• "Autorizzazione con stato" indica che il server archivia e mantiene le informazioni di autorizzazione dell'utente sul server, rendendo le autorizzazioni parte dello stato dell'applicazione
• Ciò significa che il client deve solo mantenere un "ID di autenticazione" e il server può leggere i dettagli di autenticazione dal suo database
• Ciò implica che il server mantiene un pool di autori attivi (utenti che hanno effettuato l'accesso) e interrogherà queste informazioni per ogni richiesta
• "Autorizzazione stateless" significa che il server non memorizza e mantiene le informazioni di autenticazione dell'utente, semplicemente non sa quali utenti hanno effettuato l'accesso e si affida al client per produrre informazioni di autenticazione
• Client memorizza informazioni complete di autenticazione, come chi sei (user ID), ed eventualmente i permessi, data di scadenza, ecc, questo è più che ID solo auth, quindi si è dato un nuovo nome del token
• Ovviamente il client non può essere considerato attendibile, quindi i dati di autenticazione vengono archiviati insieme a una firma generata da hash(data + secret key), dove la chiave segreta è nota solo al server, quindi è possibile verificare l'integrità dei dati del token
• Si noti che il meccanismo token garantisce semplicemente l'integrità, ma non la riservatezza, il client deve implementarlo
• Questo significa anche che per ogni richiesta il cliente deve inviare un token completo, il che comporta una larghezza di banda aggiuntiva

CONFRONTO DEL MECCANISMO

• "Cookie" è solo un'intestazione, ma con alcune operazioni precaricate sui browser
• I cookie possono essere impostati dal server e salvati automaticamente dal client e invieranno automaticamente per lo stesso dominio
• I cookie possono essere contrassegnati in httpOnlymodo da impedire l'accesso al client JavaScript
• Le operazioni precaricate potrebbero non essere disponibili su piattaforme diverse dai browser (ad es. Dispositivi mobili), il che potrebbe comportare ulteriori sforzi
• Le "intestazioni personalizzate" sono solo intestazioni personalizzate senza operazioni precaricate
• Il cliente è responsabile di ricevere, archiviare, proteggere, inviare e aggiornare la sezione di intestazione personalizzata per ogni richiesta, questo può aiutare a prevenire un semplice incorporamento di URL dannosi

RIASSUMERE

• Non c'è magia, lo stato di autenticazione deve essere archiviato da qualche parte, sul server o sul client
• È possibile implementare stateful / stateless con cookie o altre intestazioni personalizzate
• Quando le persone parlano di queste cose la loro mentalità predefinita è principalmente: stateless = token + header personalizzato, stateful = ID autenticazione + cookie; queste NON sono le uniche opzioni possibili
• Hanno vantaggi e svantaggi, ma anche per i token crittografati non è necessario archiviare informazioni riservate

collegamento

Credo che ci sia un po 'di confusione qui. La differenza significativa tra l'autenticazione basata sui cookie e ciò che è ora possibile con l' archiviazione Web HTML5 è che i browser sono creati per inviare dati sui cookie ogni volta che richiedono risorse dal dominio che li ha impostati. Non puoi impedirlo senza disattivare i cookie. I browser non inviano dati dall'archiviazione Web a meno che il codice nella pagina non li invii . E le pagine possono accedere solo ai dati che hanno archiviato, non ai dati memorizzati da altre pagine.

Pertanto, un utente preoccupato del modo in cui i suoi dati sui cookie potrebbero essere utilizzati da Google o Facebook potrebbero disattivare i cookie. Tuttavia, hanno meno motivi per disattivare l'archiviazione Web (fino a quando gli inserzionisti non riescono a utilizzarlo).

Quindi, questa è la differenza tra cookie e token, quest'ultimo utilizza l'archiviazione Web.

L'autenticazione basata su token è senza stato, il server non deve archiviare le informazioni utente nella sessione. Ciò offre la possibilità di ridimensionare l'applicazione senza preoccuparsi del luogo in cui l'utente ha effettuato l'accesso. Esiste affinità con Web Server Framework per i cookie, mentre ciò non costituisce un problema con i token. Quindi lo stesso token può essere utilizzato per recuperare una risorsa sicura da un dominio diverso da quello a cui abbiamo effettuato l'accesso che evita un'altra autenticazione uid / pwd.

Ottimo articolo qui:

http://www.toptal.com/web/cookie-free-authentication-with-json-web-tokens-an-example-in-laravel-and-angularjs

Usa token quando ...

La federazione è desiderata. Ad esempio, si desidera utilizzare un fornitore (token dispenser) come emittente di token e quindi utilizzare il proprio server api come validatore di token. Un'app può eseguire l'autenticazione con Token Dispensor, ricevere un token e quindi presentare quel token al proprio server api per la verifica. (Lo stesso vale per l'accesso a Google. O Paypal. O Salesforce.com. Ecc.)

È richiesta l'asincronia. Ad esempio, si desidera che il client invii una richiesta e quindi memorizzi tale richiesta da qualche parte, affinché venga gestita da un sistema separato "successivamente". Tale sistema separato non avrà una connessione sincrona con il client e potrebbe non avere una connessione diretta con un dispenser di token centrale. un JWT può essere letto dal sistema di elaborazione asincrono per determinare se l'elemento di lavoro può e deve essere soddisfatto in un secondo momento. Questo è, in un certo senso, correlato all'idea della Federazione sopra. Fai attenzione qui, però: JWT scade. Se la coda che contiene l'elemento di lavoro non viene elaborata entro il ciclo di vita di JWT, i reclami non dovrebbero più essere attendibili.

È richiesta la richiesta firmata Cient. Qui, la richiesta viene firmata dal client utilizzando la sua chiave privata e il server verrà convalidato utilizzando la chiave pubblica già registrata del client.

Una delle differenze principali è che i cookie sono soggetti alla stessa politica sull'origine, mentre i token no. Questo crea tutti i tipi di effetti downstream.

Poiché i cookie vengono inviati solo a un determinato host, tale host deve sostenere l'onere di autenticare l'utente e l'utente deve creare un account con i dati di sicurezza con tale host per essere verificabile.

I token invece vengono emessi e non sono soggetti alla stessa politica di origine. L'emittente può essere letteralmente chiunque e spetta all'host decidere quali emittenti fidarsi. Un emittente come Google e Facebook è in genere ben fidato, quindi un host può spostare l'onere di autenticare l'utente (inclusa la memorizzazione di tutti i dati di sicurezza dell'utente) a un'altra parte e l'utente può consolidare i propri dati personali sotto un emittente specifico e non dover ricordare un gruppo di password diverse per ogni host con cui interagiscono.

Ciò consente scenari single sign-on che riducono l'attrito complessivo nell'esperienza dell'utente. In teoria, il web diventa anche più sicuro quando emergono provider di identità specializzati per fornire servizi di autenticazione invece di avere tutti i siti Web di ma e pa che sviluppano i propri sistemi di autenticazione, probabilmente a metà. E poiché questi fornitori emergono il costo di fornire risorse Web sicure anche per tendenze di risorse molto basilari verso lo zero.

Quindi, in generale, i token riducono l'attrito e i costi associati alla fornitura dell'autenticazione e spostano l'onere dei vari aspetti di una rete sicura verso parti centralizzate in grado di implementare e mantenere sistemi di sicurezza.