Autenticazione token e cookie

Qual è la differenza tra autenticazione e autenticazione con token utilizzando i cookie?

Sto cercando di implementare la demo di Ember Auth Rails ma non capisco le ragioni che stanno dietro l’utilizzo dell’autenticazione token come descritto nelle FAQ di Auth Ember sulla domanda “Perché l’autenticazione token?”

Una tipica app Web è per lo più senza stato , a causa della sua natura di richiesta / risposta . Il protocollo HTTP è il miglior esempio di un protocollo stateless . Ma dal momento che la maggior parte delle applicazioni web ha bisogno di 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 il client stateless , conoscendo principalmente tutto lo stato dell’app, ma memorizzato nel server. In questo scenario in nessun momento il client mantiene lo stato , che non è il modo in cui funziona Ember.js .

In Ember.js le cose sono diverse. Ember.js semplifica il lavoro del programmatore perché mantiene lo stato per te, nel client, conoscendo in ogni momento il suo stato senza dover effettuare una richiesta al server che richiede i dati di stato .

Tuttavia, lo stato di conservazione nel client può anche a volte introdurre problemi di concorrenza che semplicemente non sono presenti in situazioni apolidi . Tuttavia, Ember.js si occupa anche di questo problema, in particolare i dati ember vengono creati tenendo presente questo. In conclusione, Ember.js è un framework progettato per client stateful .

Ember.js non funziona come una tipica app web stateless in cui la sessione , lo stato e i cookie corrispondenti sono gestiti quasi completamente dal server. Ember.js mantiene il suo stato completamente in javascript (nella memoria del client, e non nel DOM come in altri framework) e non ha bisogno del server per gestire la sessione. Questo fa sì che Ember.js sia più versatile in molte situazioni, ad esempio quando la tua app è in modalità offline.

Ovviamente per motivi di sicurezza necessita di qualche tipo di token o chiave univoca da inviare al server ogni volta che viene effettuata una richiesta per essere autenticata , 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 parere, il motivo principale per cui utilizzare un token di autenticazione anziché i cookie, come indicato nelle domande frequenti di autenticazione di Ember, dipende principalmente dalla natura del framework Ember.js e anche dal fatto che si adatta maggiormente al paradigma delle app Web stateful . Pertanto, il meccanismo dei cookie non è l’approccio migliore quando si crea un’app Ember.js.

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

Http è senza stato. 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 specifiche intestazioni http, 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 authorization vengono inviati per ogni singola richiesta.)
    • Immune to XSRF (breve esempio di XSRF – Ti invieremo un link in email che assomiglierà a , e se sei loggato tramite autenticazione dei cookie su bank.com, e bank.com non ha alcun mezzo di protezione XSRF, preleverò denaro dal tuo account semplicemente dal fatto che il tuo browser attiverà una richiesta GET autorizzata a quell’URL.) Nota ci sono misure anti contraffazione che puoi fare con l’autenticazione basata su cookie – ma devi implementarle.
    • I cookie sono legati a un singolo dominio. Un cookie creato sul dominio foo.com non può essere letto dal dominio bar.com, mentre puoi inviare token a qualsiasi dominio che ti piace. Ciò è particolarmente utile per le applicazioni a pagina singola che stanno consumando più servizi che richiedono un’authorization – quindi posso avere un’app Web sul dominio myapp.com che può effettuare richieste client-side autorizzate su myservice1.com e su myservice2.com.
  • Contro:
    • Devi conservare il token da qualche parte; mentre i cookie sono archiviati “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 link in una nuova scheda renderà quella scheda anonimo) e cookie (Pro: il token viene scartato dopo aver chiuso la finestra del browser. Se utilizzi un cookie di sessione verrai autenticato quando apri un link in una nuova scheda e sarai immune da XSRF poiché stai ignorando il cookie per l’autenticazione, lo stai solo utilizzando come token storage Con: i cookie vengono inviati per ogni singola richiesta.Se questo cookie non è contrassegnato come https, sei aperto agli attacchi man in the middle.)
    • È leggermente più semplice eseguire un attacco XSS contro l’autenticazione basata su token (cioè se sono in grado di eseguire uno script sul tuo sito, posso rubare il tuo token, tuttavia l’autenticazione basata su cookie non è un proiettile argentato – mentre i cookie contrassegnati come http non può essere letto dal client, il client può comunque effettuare richieste per conto dell’utente che includeranno automaticamente il cookie di authorization.)
    • Le richieste di download di un file, che dovrebbe funzionare solo per gli utenti autorizzati, richiedono l’utilizzo di File API. La stessa richiesta funziona immediatamente per l’autenticazione basata su cookie.

Autenticazione dei cookie

  • Una richiesta al server è sempre autenticata dal cookie di authorization.
  • Professionisti:
    • I cookie possono essere contrassegnati come “http-only” che li rende impossibili da leggere sul lato client. Questo è meglio per la protezione dagli attacchi XSS.
    • Viene fornito immediatamente, non è necessario implementare alcun codice sul lato client.
  • Contro:
    • Associato a un singolo dominio. Quindi, se si dispone di un’applicazione a singola pagina che effettua richieste a più servizi, si può finire per fare cose pazzesche come un proxy inverso.
    • Vulnerabile a XSRF. È necessario implementare ulteriori misure per rendere il sito protetto contro le falsificazioni delle richieste cross site.
    • Vengono inviati per ogni singola richiesta (anche per richieste che non richiedono l’autenticazione).

In generale, direi che i token ti danno una maggiore flessibilità, (dal momento che non sei legato a un singolo dominio). Il rovescio della medaglia è che devi fare un po ‘di programmazione da solo.

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

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

  • L’archiviazione locale / di sessione non funziona su tutti i domini, usa un cookie marcatore

  • 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 su ogni richiesta, fai attenzione alle sue dimensioni

  • Se memorizzi 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 delle tue autorizzazioni

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/

Credo che ci sia un po ‘di confusione qui. La differenza significativa tra l’autenticazione basata su cookie e ciò che è ora ansible con HTML5 Web Storage è che i browser sono costruiti per inviare dati sui cookie ogni volta che richiedono risorse dal dominio che li ha impostati. Non è ansible impedirlo senza distriggersre i cookie. I browser non inviano dati da Archiviazione Web a meno che il codice nella pagina non li invii . E le pagine possono solo accedere ai dati che hanno memorizzato, non i 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 potrebbe distriggersre i cookie. Ma hanno meno motivi per distriggersre il Web Storage (fino a quando gli inserzionisti non capiranno come usarlo).

Quindi, questa è la differenza tra cookie basati e basati su token, quest’ultimo usa Web Storage.

L’autenticazione basata su token è stateless, il server non deve memorizzare le informazioni dell’utente nella sessione. Questo dà la possibilità di ridimensionare l’applicazione senza preoccuparsi di dove l’utente abbia effettuato l’accesso. Esiste affinità con Web Server Framework per i cookie, mentre non si tratta di un problema basato su token. Quindi lo stesso token può essere utilizzato per prelevare una risorsa sicura da un dominio diverso da quello in cui è stato 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

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

Poiché i cookie vengono inviati e ricevuti da un particolare host, l’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 d’altra parte sono emessi e non sono soggetti alla stessa politica di origine. L’emittente può essere letteralmente chiunque e spetta all’host decidere quali emittenti fare affidamento. Un emittente come Google e Facebook è in genere ben fidato, pertanto 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 in un emittente specifico e non deve ricordare un una serie di password diverse per ogni host con cui interagiscono.

Ciò consente il single sign su scenari che riducono l’attrito complessivo nell’esperienza utente. In teoria il web diventa anche più sicuro quando emergono provider di identity framework specializzati per fornire servizi di autenticazione invece di fare in modo che tutti i siti Web di ma e pa girino su sistemi di autenticazione autenticati. E come questi fornitori emergono il costo di fornire risorse web sicure anche per le tendenze di risorse molto elementari verso zero.

Pertanto, in generale, i token riducono l’attrito e i costi associati alla fornitura dell’autenticazione e spostano il carico dei vari aspetti di un Web sicuro verso parti centralizzate in grado di implementare e mantenere sistemi di sicurezza.