2013-07-21 4 views
108

Qualcuno può darmi una descrizione passo passo di come funziona l'autenticazione basata su cookie? Non ho mai fatto nulla che riguardasse l'autenticazione o i cookie. Cosa deve fare il browser? Cosa deve fare il server? In che ordine? Come manteniamo le cose al sicuro?Come funziona l'autenticazione basata su cookie?

Ho letto su diversi tipi di autenticazione e sui cookie, ma vorrei una descrizione di base su come utilizzare i due insieme - ho letto solo che sono spesso usati insieme ma non sono riusciti a trovare una descrizione di Come.

+3

http://www.howstuffworks.com/cookie.htm – Cyclonecode

+0

questo articolo può aiutare: http://www.yegor256.com/2015/05/18/cookie-based-authentication.html – yegor256

risposta

93

Un cookie è fondamentalmente solo un elemento in un dizionario. Ogni oggetto ha una chiave e un valore. Per l'autenticazione, la chiave potrebbe essere qualcosa come "username" e il valore sarebbe il nome utente. Ogni volta che si effettua una richiesta a un sito Web, il browser includerà i cookie nella richiesta e il server host controllerà i cookie. Quindi l'autenticazione può essere eseguita automaticamente in questo modo.

Per impostare un cookie, è sufficiente aggiungerlo alla risposta che il server restituisce dopo le richieste. Il browser aggiungerà il cookie dopo aver ricevuto la risposta.

Ci sono diverse opzioni che è possibile configurare per il lato del server dei cookie, come i tempi di scadenza o la crittografia. Un cookie crittografato viene spesso definito cookie firmato. Fondamentalmente il server crittografa la chiave e il valore nella voce dizionario, quindi solo il server può fare uso delle informazioni. Quindi il cookie sarebbe sicuro.

Un browser salverà i cookie impostati dal server. Nell'intestazione HTTP di ogni richiesta effettuata dal browser a quel server, verranno aggiunti i cookie. Aggiungerà solo i cookie per i domini che li impostano. Example.com può impostare un cookie e anche aggiungere opzioni nell'intestazione HTTP per consentire ai browser di inviare il cookie ai sottodomini, come sub.example.com. Sarebbe inaccettabile che un browser invii mai i cookie a un dominio diverso.

+0

Cosa capisco è che il browser è in grado di inviare i cookie allo stesso dominio. In relazione a ciò il browser prende in considerazione il sottodominio quando si distingue tra due domini? – Aakash

+1

È possibile impostare le opzioni nell'intestazione HTTP per il modo in cui un browser gestisce i sottodomini. –

151

Mi rendo conto che è in ritardo di anni, ma ho pensato di poter ampliare la risposta di Conor e aggiungere un po 'di più alla discussione.

Qualcuno può darmi una descrizione passo passo di come funziona l'autenticazione basata su cookie? Non ho mai fatto nulla che riguardasse l'autenticazione o i cookie. Cosa deve fare il browser? Cosa deve fare il server? In che ordine? Come manteniamo le cose al sicuro?

Fase 1: client> L'iscrizione

Prima di ogni altra cosa, l'utente deve registrarsi. Il client invia una richiesta HTTP al server contenente il suo nome utente e la sua password.

Fase 2: Server> Gestione iscriversi

Il server riceve la richiesta e gli hash della password prima di memorizzare il nome utente e la password nel database. In questo modo, se qualcuno accede al tuo database, non vedranno le password effettive degli utenti.

Fase 3: client> User login

Ora i vostri utente accede a Lui/lei fornisce un nome utente/password e di nuovo, questo viene inviato come una richiesta HTTP al server..

Fase 4: Server> Convalida login

Il server cerca il nome utente nel database, hash della password di login in dotazione, e lo confronta con la password precedentemente hash nel database. In caso contrario, potremmo negare l'accesso al numero sending a 401 status code and ending the request.

Fase 5: Server> Generazione token di accesso

Se tutto procede, stiamo andando a creare un token di accesso, che identifica in modo univoco la sessione dell'utente. Sempre nel server, facciamo due cose con il token di accesso:

  1. Conservare nel database associato a tale utente
  2. allegarlo a un cookie risposta da restituire al client. Assicurati di impostare una data/ora di scadenza per limitare la sessione dell'utente

D'ora in poi, i cookie verranno allegati a ogni richiesta (e risposta) effettuata tra client e server.

Passo 6: client> Pagina effettuare richieste

Torna sul lato client, ci sono ora registrati nel Ogni volta che il client effettua una richiesta per una pagina che richiede l'autorizzazione (vale a dire che hanno bisogno di essere registrato. in), il server ottiene il token di accesso dal cookie e lo confronta con quello nel database associato a tale utente. Se viene estratto, l'accesso è garantito.

Questo dovrebbe iniziare. Assicurati di cancellare i cookie al logout! Autenticazione

+4

Grazie per la descrizione. Mi chiedo solo in che modo l'accesso token fornisce sicurezza? Può un utente malintenzionato se ruba il cookie, si comporta come un utente autenticato che ha effettuato l'accesso? O quello è protetto da SSL? – Richeek

+1

@Richeek SSL protegge l'intercettazione durante le richieste/risposte, ma un utente malintenzionato potrebbe accedere ai cookie sugli endpoint (ad es. Il browser). Teoricamente, potrebbero quindi posare come utente registrato fino alla scadenza del cookie. Dico "teoricamente" perché l'implementazione sopra non lo gestisce. Nell'implementazione di cui sopra, l'utente malintenzionato avrà accesso finché il token di accesso nel database non sarà aggiornato (ad esempio, il prossimo accesso). – pllx

+7

Potrebbe invalidare il token di accesso alla scadenza, magari con una "data di scadenza" nel database. Oppure potresti prendere in considerazione l'utilizzo di [JSON Web Tokens (JWT)] (http://techarena51.com/index.php/json-web-token-authentication-with-flask-and-angularjs/), che sono come token di accesso , ma può gestire la scadenza del token, tra le altre cose. [Maggiori informazioni su JWT qui.] (Http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html#rfc.section.4.1.4) Un utente malintenzionato avrà comunque accesso al tuo account per brevi periodi di tempo se hanno il token di accesso/JWT, quindi devi proteggere anche i tuoi endpoint. – pllx

0

basata su cookie di autenticazione

cookie in base funziona normalmente in questi 4 steps-

  1. L'utente fornisce un nome utente e password nel form di login e fa clic su Accedi.
  2. Dopo aver effettuato la richiesta, il server convalida l'utente sul back-end effettuando una query nel database. Se la richiesta è valida, creerà una sessione utilizzando le informazioni utente recuperate dal database e le memorizzerà, per ogni sessione verrà creato un ID univoco chiamato ID di sessione, per impostazione predefinita l'ID di sessione verrà dato al client tramite il browser.
  3. Il browser invierà questo ID di sessione a ciascuna richiesta successiva, l'ID di sessione viene verificato rispetto al database, in base a questo sito Web identificativo di sessione identificherà la sessione di appartenenza a tale client e quindi darà accesso alla richiesta.

  4. Una volta che l'utente si disconnette dall'app, la sessione viene distrutta sia lato client che lato server.