Autenticazione sessione vs Autenticazione token

Naviga le tue risposte
91

Sto cercando di ottenere un controllo su alcuni termini e meccanismi e scoprire come si relazionano tra loro o come si sovrappongono. L'autenticazione di un'applicazione web teorica e di un'applicazione mobile è l'obiettivo. L'attenzione si concentra sulla differenza esatta tra autenticazione basata su token e autenticazione basata su cookie e se / come si intersecano.

link

Ho alcune asserzioni che vorrei pubblicare e vedere se sono corrette.

  1. È possibile utilizzare solo token di autenticazione senza sessioni nelle applicazioni mobili. In un contesto del browser sono necessari i cookie per mantenere i token sui client.
  2. Si scambiano le proprie credenziali (di solito username / pw) per un token che può essere limitato nello scope e nel tempo. Ma questo significa anche che il token e tutto ciò che lo riguarda deve essere persistito e gestito dal server.
  3. I token possono essere revocati dal lato server. I cookie non hanno questa opzione e / dovrebbero scadere.
  4. L'utilizzo dei soli cookie indica che sessionid è correlato all'account utente e non limitato in alcun modo.

Spero di non essere troppo lontano dal marchio e sono grato per qualsiasi aiuto!

    
posta Hoax 16.02.2015 - 10:04
fonte

3 risposte

101

  1. In Autenticazione basata sulla sessione il server esegue tutte le operazioni di sollevamento dal lato server. In generale, un client si autentica con le sue credenziali e riceve un session_id (che può essere memorizzato in un cookie) e lo allega ad ogni successiva richiesta in uscita. Quindi questo potrebbe essere considerato un "token" in quanto è l'equivalente di un insieme di credenziali. Tuttavia, non c'è niente di speciale in questo session_id-String. È solo un identificatore e il server fa tutto il resto. È stato. Associa l'identificatore con un account utente (ad es. In memoria o in un database). Può limitare o limitare questa sessione a determinate operazioni o un certo periodo di tempo e può invalidarla se ci sono problemi di sicurezza e, cosa più importante, può fare e modificare tutto questo al volo. Inoltre, può registrare gli utenti ogni mossa sui siti Web. I possibili svantaggi sono la cattiva capacità di scalabilità (specialmente su più di una server farm) e l'uso intensivo della memoria.

  2. In Autenticazione basata su token nessuna sessione è persistente lato server (senza stato). I passi iniziali sono gli stessi. Le credenziali vengono scambiate con un token che viene poi allegato a ogni richiesta successiva (può anche essere memorizzato in un cookie). Tuttavia, al fine di ridurre l'utilizzo della memoria, la facilità di scalabilità e la flessibilità totale (i token possono essere scambiati con un altro client) viene emessa una stringa con tutte le informazioni necessarie (il token) che viene verificata dopo ogni richiesta fatta dal cliente al server. Esistono diversi modi per utilizzare / creare token:

a) utilizzando un meccanismo di hash ad es. HMAC-SHA1 

token = user_id|expiry_date|HMAC(user_id|expiry_date, k)

- id e expiry_id sono inviati in chiaro con l'hash risultante allegato (k è noto solo al server)

b) crittografare il token simmetricamente, ad es. con AES 

token = AES(user_id|expiry_date, x)

- x rappresenta la chiave en / decryption

c) crittografandolo asimmetricamente, ad es. con RSA 

token = RSA(user_id|expiry_date, private key)

I sistemi produttivi sono in genere più complessi di questi due archetipi. Ad esempio, Amazon utilizza entrambi i meccanismi sul proprio sito web. Anche gli ibridi possono essere utilizzati per emettere token come descritto in 2 e anche associare una sessione utente con esso per il tracciamento degli utenti o la possibile revoca e mantenere comunque la flessibilità del client dei token classici. Inoltre, OAuth 2.0 utilizza token al portatore a vita breve e specifici e token di aggiornamento a vita più lunga, ad es. per ottenere segnalini portatori.

Fonti:

risposta data 21.06.2015 - 14:30
fonte
6

HTTP è senza stato e, per avere uno stato autenticato, è necessario un tipo di token utilizzato per fare riferimento alle informazioni sull'utente. Questo ID di sessione è solitamente sotto forma di token casuale inviato come valore del cookie. Un OAuth Token di accesso viene utilizzato per identificare un utente e il scope di risorse a cui l'utente ha accesso. Nelle applicazioni che utilizzano OAuth con accesso singolo, un token di accesso OAuth viene scambiato in genere per un ID sessione che può tenere traccia di una più ampia varietà di stato utente.

Dal punto di vista di un utente malintenzionato, il dirottamento di un ID di sessione o del token di accesso OAuth è buono come un nome utente e una password, ea volte è ancora meglio. Gli ID di sessione devono avere proprietà di sicurezza che proteggono gli account degli utenti da eventuali compromissioni.

Dal punto di vista dello sviluppatore, non reinventa mai la ruota . Utilizzare il gestore sessioni fornito dalla piattaforma e assicurarsi che sia configurato per conformarsi alle Linee guida per la gestione della sessione OWASP .

    
risposta data 16.02.2015 - 16:04
fonte
0

Quindi, sull'autenticazione basata sulla sessione, per aumentare la sicurezza nell'accesso alle risorse di cui si ha bisogno:

  • Dovrebbe essere usato in sostituzione delle credenziali di un utente
  • Dovrebbe sempre utilizzare un cookie persistente
  • Dovrebbe identificare gli utenti che ritornano al sito web
  • Dovrebbe usare l'autenticazione a 2 fattori
risposta data 02.11.2018 - 01:49
fonte

Leggi altre domande sui tag

Perché usiamo ancora le chiavi per avviare le auto? perché non le password? C'è una soglia per una password così a lungo che non diventa più sicura o addirittura diventa insicura?