Memorizza token di autenticazione in cookie o intestazione?

Question

Memorizza token di autenticazione in cookie o intestazione?

#1 da (6 voti)

5

Capisco che un'intestazione sia la soluzione "più pulita" per trasportare un token di autenticazione da un sistema fidato a un altro in una chiamata REST. Ma quando ti trovi nel codice JavaScript lato client, il mondo mi sembra diverso.

I cookie possono essere contrassegnati come "solo http" e quindi non possono essere facilmente rubati da JavaScript. Anche l'intestazione deve essere impostata da JavaScript, quindi il token di autenticazione deve essere accessibile da JavaScript. Tuttavia, le persone utilizzano le intestazioni auth per inviare i loro token di autenticazione da un client JavaScript non affidabile al server.

Che cosa è cambiato dal buon vecchio "usa i cookie con flag solo http e solo" per "lasciare che JavaScript gestisca il token di autenticazione"? O dovrebbe essere il modo giusto di essere "sul lato client, utilizzare i cookie e non appena si entra nel mondo fidato, passare a auth-header"?

PS: So che ci sono molte risposte a domande simili, ma penso che le mie domande siano da un altro punto di vista "cosa è cambiato, è diverso".

api rest authentication cookies

posta rdmueller 23.02.2018 - 07:43

fonte

1 risposta

Leggi altre domande sui tag api rest authentication cookies

Sono necessari i flag HttpOnly o Secure se nessun login? Qualcuno ha chiamato il mio cellulare per offrire servizi su qualcosa che stavo cercando nel web

score 6 · Accepted Answer

Autenticazione basata su cookie

Pro

Http Only Flag : i cookie di sessione possono essere creati con il flag HttpOnly che protegge i cookie da JavaScript dannoso (XSS-Cross-Site Scripting).
Flag sicuro : i cookie di sessione possono essere creati con il flag Secure che impedisce la trasmissione di cookie su un canale non criptato.

Contro

CSRF : i cookie sono vulnerabili / vulnerabili agli attacchi CSRF poiché i cookie di terze parti vengono inviati per impostazione predefinita al dominio di terze parti che causa lo sfruttamento della vulnerabilità CSRF.
Prestazioni e scalabilità : l'autenticazione basata su cookie è un'autenticazione di stato tale che il server deve memorizzare i cookie in un file / DB per mantenere lo stato di tutti gli utenti. Con l'aumentare della base di utenti, il server di backend deve mantenere un sistema separato in modo da memorizzare i cookie di sessione.

Autenticazione basata su token:

Pro

Prestazioni e scalabilità : i token contengono i metadati e il relativo valore firmato (per la protezione anti-manomissione). Sono auto-contenuti e quindi non è necessario mantenere lo stato sul server. Ciò migliora le prestazioni e quindi la scalabilità quando è richiesta l'espansione.
CSRF : a differenza dell'autenticazione basata su cookie, l'autenticazione basata su token non è suscettibile di falsificazione di richieste tra siti poiché i token non vengono inviati alle applicazioni Web di terze parti per impostazione predefinita.

Contro

XSS : poiché i token di sessione sono memorizzati nella memoria dati locale del browser ed è accessibile al JS dello stesso dominio. Quindi non esiste alcuna opzione per proteggere l'identificatore di sessione dagli attacchi XSS a differenza del flag di sicurezza HTTPOnly che è disponibile nell'autenticazione basata su cookie.

Conclusione

Entrambi i meccanismi hanno i loro pro e contro come accennato. Nell'era attuale dei Framework di sviluppo delle applicazioni , i professionisti come XSS e CSRF sono presi in quadro di riferimento stesso e quindi ritengo che sia senza dubbio un chiaro compromesso su cui gli sviluppatori e le parti interessate prendono la decisione.