Comment fonctionne l'authentification basée sur les cookies?


210

Quelqu'un peut-il me donner une description étape par étape du fonctionnement de l'authentification basée sur les cookies? Je n'ai jamais rien fait impliquant l'authentification ou les cookies. Que doit faire le navigateur? Que doit faire le serveur? Dans quel ordre? Comment sécurisons-nous les choses?

J'ai lu sur différents types d'authentification et sur les cookies, mais je voudrais une description de base de la façon d'utiliser les deux ensemble.J'ai seulement lu qu'ils sont souvent utilisés ensemble, mais je n'ai pas pu trouver de description de la façon.


Réponses:


162

Un cookie est simplement un élément d'un dictionnaire. Chaque élément a une clé et une valeur. Pour l'authentification, la clé pourrait être quelque chose comme «nom d'utilisateur» et la valeur serait le nom d'utilisateur. Chaque fois que vous faites une demande à un site Web, votre navigateur inclura les cookies dans la demande, et le serveur hôte vérifiera les cookies. L'authentification peut donc se faire automatiquement comme ça.

Pour définir un cookie, il vous suffit de l'ajouter à la réponse que le serveur renvoie après les demandes. Le navigateur ajoutera alors le cookie dès réception de la réponse.

Il existe différentes options que vous pouvez configurer côté serveur de cookies, comme les délais d'expiration ou le chiffrement. Un cookie crypté est souvent appelé cookie signé. Fondamentalement, le serveur crypte la clé et la valeur dans l'élément de dictionnaire, de sorte que seul le serveur peut utiliser les informations. Ainsi, le cookie serait sécurisé.

Un navigateur enregistrera les cookies définis par le serveur. Dans l'en-tête HTTP de chaque demande que le navigateur fait à ce serveur, il ajoutera les cookies. Il n'ajoutera que des cookies pour les domaines qui les ont définis. Example.com peut définir un cookie et également ajouter des options dans l'en-tête HTTP pour que les navigateurs renvoient le cookie vers des sous-domaines, comme sub.example.com. Il serait inacceptable qu'un navigateur envoie des cookies vers un autre domaine.


Ce que je comprends, c'est que le navigateur est en mesure de renvoyer le cookie vers le même domaine. Par rapport à cela, le navigateur prend-il en compte le sous-domaine lorsqu'il différencie deux domaines?
Aakash

1
Vous pouvez définir des options dans l'en-tête HTTP pour la façon dont un navigateur gère les sous-domaines.
Conor Patrick

288

Je me rends compte que c'est des années en retard, mais j'ai pensé que je pourrais développer la réponse de Conor et ajouter un peu plus à la discussion.

Quelqu'un peut-il me donner une description étape par étape du fonctionnement de l'authentification basée sur les cookies? Je n'ai jamais rien fait impliquant l'authentification ou les cookies. Que doit faire le navigateur? Que doit faire le serveur? Dans quel ordre? Comment sécurisons-nous les choses?

Étape 1: Client> Inscription

Avant toute chose, l'utilisateur doit s'inscrire. Le client envoie une requête HTTP au serveur contenant son nom d'utilisateur et son mot de passe.

Étape 2: Serveur> Gestion de l'inscription

Le serveur reçoit cette demande et hache le mot de passe avant de stocker le nom d'utilisateur et le mot de passe dans votre base de données. De cette façon, si quelqu'un accède à votre base de données, il ne verra pas les mots de passe réels de vos utilisateurs.

Étape 3: Client> Connexion utilisateur

Maintenant, votre utilisateur se connecte. Il / elle fournit son nom d'utilisateur / mot de passe et encore une fois, cela est publié comme une requête HTTP au serveur.

Étape 4: Serveur> Validation de la connexion

Le serveur recherche le nom d'utilisateur dans la base de données, hache le mot de passe de connexion fourni et le compare au mot de passe haché précédemment dans la base de données. S'il ne vérifie pas, nous pouvons leur refuser l'accès en envoyant un code d'état 401 et en mettant fin à la demande .

Étape 5: Serveur> Génération d'un jeton d'accès

Si tout se passe bien, nous allons créer un jeton d'accès, qui identifie de manière unique la session de l'utilisateur. Toujours sur le serveur, nous faisons deux choses avec le jeton d'accès:

  1. Stockez-le dans la base de données associée à cet utilisateur
  2. Attachez-le à un cookie de réponse à retourner au client. Assurez-vous de définir une date / heure d'expiration pour limiter la session de l'utilisateur

Désormais, les cookies seront attachés à chaque demande (et réponse) faite entre le client et le serveur.

Étape 6: Client> Faire des demandes de page

De nouveau côté client, nous sommes maintenant connectés. Chaque fois que le client fait une demande de page nécessitant une autorisation (c'est-à-dire qu'il doit être connecté), le serveur obtient le jeton d'accès à partir du cookie et le vérifie par rapport à celui dans la base de données associée à cet utilisateur. S'il vérifie, l'accès est accordé.

Cela devrait vous aider à démarrer. Assurez-vous d'effacer les cookies lors de la déconnexion!


10
Merci pour la description. Je me demande simplement comment le jeton d'accès assure la sécurité? Un attaquant peut-il, s'il vole le cookie, se faire passer pour un utilisateur connecté authentifié? Ou qui est protégé par SSL?
Richeek

6
@Richeek SSL sécurise l'interception lors des demandes / réponses, mais un attaquant peut accéder à vos cookies aux points de terminaison (par exemple votre navigateur). Théoriquement, ils pourraient alors se présenter comme un utilisateur connecté jusqu'à l'expiration du cookie. Je dis «théoriquement» parce que l'implémentation ci-dessus ne gère pas cela. Dans l'implémentation ci-dessus, l'attaquant aura accès jusqu'à la mise à jour du jeton d'accès dans votre base de données (c'est-à-dire la prochaine connexion).
pllx

14
Vous pouvez invalider le jeton d'accès à l'expiration vous-même, peut-être avec une «date d'expiration» dans votre base de données. Vous pouvez également envisager d'utiliser des jetons Web JSON (JWT) , qui sont comme des jetons d'accès, mais peuvent gérer l'expiration des jetons, entre autres. Plus d'informations sur JWT ici. Un attaquant aura toujours accès à votre compte pendant de brèves périodes s'il dispose de votre jeton d'accès / JWT, vous devez donc également sécuriser vos points de terminaison.
pllx

3
Il m'a fallu longtemps pour vous dire merci! Merci pour votre explication
Richeek

4
@ManuChadha, avec la clé de jeton / session, vous pouvez également enregistrer l'adresse IP de l'utilisateur ainsi que d'autres paramètres d'identification tels que l'agent utilisateur, etc. si la demande est ensuite accompagnée d'un cookie valide, mais de la mauvaise IP, du mauvais navigateur, etc., alors vous refuser la demande et rediriger l'utilisateur vers la page de connexion pour s'authentifier à nouveau.
FalcoGer

18

Authentification basée sur les cookies

L'authentification basée sur les cookies fonctionne normalement dans ces 4 étapes-

  1. L'utilisateur fournit un nom d'utilisateur et un mot de passe dans le formulaire de connexion et clique sur Connexion.
  2. Une fois la demande effectuée, le serveur valide l'utilisateur sur le serveur principal en effectuant une requête dans la base de données. Si la demande est valide, elle créera une session en utilisant les informations utilisateur extraites de la base de données et les stockera, pour chaque session un ID unique appelé ID de session est créé, par défaut l'ID de session est donné au client via le navigateur.
  3. Le navigateur soumettra cet ID de session à chaque demande ultérieure, l'ID de session est vérifié par rapport à la base de données, sur la base de cet identifiant de session, le site Web identifiera la session appartenant à quel client, puis donnera accès à la demande.

  4. Une fois qu'un utilisateur se déconnecte de l'application, la session est détruite côté client et côté serveur.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.