Les JSON Web Tokens et les cookies de session offrent tous deux une authentification utilisateur pour les sites Web et les applications, mais ce n’est pas la même chose.

Vous trouverez ci-dessous plus de détails sur les JSON Web Tokens et les cookies de session, ainsi que les principales différences entre eux.

Point commun entre JSON Web Token et Cookies de session

Avant d’entrer dans les différences entre les jetons Web JSON et les cookies de session, il est essentiel de comprendre d’abord leur principale similitude. Ils peuvent tous les deux être utilisés pour authentifier les utilisateurs lorsqu’ils cliquent sur différentes pages et après s’être connectés à un site Web ou à une application.

Sans eux, par exemple, vous devriez continuer à vous connecter après chaque page que vous cliquez pour visiter.

Le protocole HTTP (Hypertext Transfer Protocol) est le fondement du Web. Il transmet des données telles que des documents HTML.

C’est aussi apatride. Cela signifie que lorsque vous visitez une page Web, puis cliquez sur une autre sur le même site, vos actions précédentes ne sont pas mémorisées dans la mémoire du serveur.

Donc, si vous vous connectez et visitez une autre page à laquelle vous devriez avoir accès, vous seriez obligé de vous connecter à nouveau puisque HTTP ne garderait pas une trace du fait que vous venez de vous connecter.

Les jetons Web JSON et les cookies de session résolvent ce problème en conservant certaines données utilisateur authentifiées à chaque nouvelle demande.

En d’autres termes, les deux options gardent votre statut de connexion en mémoire afin que vous puissiez parcourir autant de pages protégées par mot de passe que vous le souhaitez sans avoir à vous reconnecter – au moins pour la durée de votre visite, ou jusqu’à votre déconnexion.

Les jetons Web JSON et les cookies de session sont également des options sécurisées que vous pouvez utiliser.

C’est à peu près là que les similitudes s’arrêtent. Quelles sont les principales différences entre les jetons Web JSON et les cookies de session ?

Que sont les Cookies de session ?

Les cookies de session utilisent l’authentification par session. L’état de connexion d’un utilisateur est enregistré dans la mémoire du serveur.

Après qu’un utilisateur se soit connecté, une session est créée en toute sécurité par le serveur. Ensuite, cet identifiant de session est stocké dans un cookie de session sur le navigateur de l’utilisateur. Tant que l’utilisateur reste connecté, le cookie est envoyé avec chaque demande ultérieure.

A chaque demande, le serveur consulte le cookie de session pour lire l’ID de session. S’il correspond aux données stockées dans sa mémoire, il renvoie une réponse au navigateur pour lui faire savoir que tout va bien et qu’il est prêt à partir.

C’est alors que la session est authentifiée et que l’utilisateur est libre de parcourir la page protégée par mot de passe. Lorsqu’ils cliquent sur une autre page protégée, le processus se répète.

Que sont les JSON Web Token ?

JSON Web Token est souvent abrégé en JWT et se prononce communément “jot”.

Un jeton Web JSON prend les données JASON, appelé claim, et les transfère en toute sécurité. Il le fait en signant cryptographiquement la revendication. La signature est signée symétriquement ou asymétriquement, mais les deux offrent une authentification.

Ce processus est une forme d’authentification par jeton.

Les jetons Web JSON fonctionnent de la même façon qu’un numéro de compte bancaire sur un chèque, et la signature qui y est apposée pour approuver le transfert d’argent avec le chèque.

Si vous louez un appartement et que vous voulez payer le loyer par chèque, votre nom attaché à votre numéro de compte bancaire est semblable à une réclamation.

Ce sont des détails de base à votre sujet qui doivent être transmis si vous voulez payer votre loyer. C’est semblable à une réclamation parce qu’une réclamation contient quelques détails à votre sujet qui sont sauvegardés après que vous vous êtes connecté ou que votre identité a été autorisée afin de visiter des pages protégées par un mot de passe.

Le fait de pouvoir utiliser le site Web ou l’application après s’être connecté serait comme payer son loyer dans cette analogie.

Le chèque doit également porter votre signature. Votre signature est propre à vous et indique à la banque que vous autorisez l’opération. Comme cette signature vous est propre, la banque peut être certaine que vous êtes bien celui que vous prétendez être et que la transaction peut être conclue.

Votre signature sur le chèque est comme la signature cryptographique d’un jeton Web JSON. Dans un JWT, cette signature est capable d’autoriser que c’est bien vous qui voulez accéder à un site ou une application.

Mais il y a un truc qui cloche : Que se passe-t-il si votre propriétaire ou votre propriétaire n’a pas reçu votre chèque signé avec votre numéro de compte bancaire et votre nom ? Que se passe-t-il si vous payez le loyer en donnant une enveloppe de liquide sans autres détails ?

Votre propriétaire ou votre propriétaire obtiendrait la valeur d’un immeuble de locataires en leur envoyant des enveloppes d’argent comptant sans aucun moyen réel de vérifier que c’est de vous ou d’un de leurs locataires. Aie ! Quel désordre.

Lorsque vous utilisez des jetons Web JSON, c’est comme si vous remettiez un chèque pour payer un loyer au lieu d’une enveloppe d’argent non marquée – votre identité peut être autorisée en toute confiance et le processus de paiement du loyer peut être terminé.

Avec les jetons Web JSON, votre identité est vérifiée sans équivoque et vous pouvez continuer à naviguer sur le site Web ou l’application où vous vous êtes connecté.

Il peut également être important de noter qu’un jeton Web JSON se compose de trois parties principales séparées par des points : Un en-tête, une charge utile et une signature.

Pour plus de détails, consultez la section Introduction aux jetons Web JSON.

Les diffénces entre les JSON Web Token et les Cookies de Session

Les jetons Web JSON et les cookies de session offrent tous deux des formes sécurisées d’authentification de l’utilisateur, ce qui est formidable. Mais en quoi diffèrent-ils ?

Les différences spécifiques et principales entre elles sont détaillées ci-dessous.

Signatures cryptographiques

Les jetons Web JSON ont des signatures cryptographiques, ce qui n’est pas le cas des cookies de session.

JSON est apatride

Les jetons Web JSON sont sans état parce que les réclamations sont stockées côté client, plutôt que dans la mémoire du serveur.

L’authentification peut se faire localement, au lieu de se faire par requête, où les requêtes doivent passer par la base de données du serveur, ou par des emplacements similaires. Cela signifie qu’un utilisateur peut être authentifié plusieurs fois sans avoir à communiquer avec la base de données du site ou de l’application, et sans utiliser une grande partie de ses ressources dans le processus.

Évolutivité

Parce que les cookies de session sont stockés dans la mémoire du serveur, il y a la possibilité d’utiliser beaucoup plus de ressources si le site ou l’application voit beaucoup de trafic. Parce que les jetons Web JSON sont sans état, ils peuvent potentiellement économiser sur les ressources du serveur dans de nombreux cas.

Cela signifie également que les jetons Web JSON ont tendance à être beaucoup plus évolutifs en conséquence.

Authentification sur plusieurs sites

Les cookies de session ne fonctionnent que sur un seul domaine ou sur ses sous-domaines. S’ils essaient d’accéder à un tiers, les navigateurs ont tendance à les désactiver. Ceci est particulièrement problématique si vous voulez que votre site Web ait une connexion sécurisée avec une API qui utilise un domaine différent.

Avec les jetons Web JSON, vous pouvez authentifier un utilisateur sur plusieurs sites, y compris plusieurs domaines, appareils mobiles et API, pour n’en nommer que quelques-uns. C’est parce qu’ils sont stockés localement dans l’en-tête de la requête.

Lequel devriez-vous utiliser ?

Bien que les jetons Web JSON et les cookies de session soient tous deux des options viables, vous pouvez parfois vouloir utiliser l’un plutôt que l’autre.

Pour les petits et moyens sites Web qui n’ont besoin que d’ouvrir une session et d’accéder à quelques détails qui sont stockés dans la base de données de votre site, les cookies de session sont généralement suffisants.

Si vous avez un site d’entreprise ou une application, et que vous avez besoin de traiter un grand nombre de demandes, en particulier avec des tiers, ou un grand nombre de tiers, y compris des API à un domaine différent, les clés Web JSON sont plus appropriées.

Gardez à l’esprit qu’il s’agit de recommandations générales puisque chaque site Web est différent et a ses propres besoins spécifiques. Cela devrait vous donner une longueur d’avance sur ce que vous voudrez peut-être utiliser dans votre cas.

Conclusion

Les jetons Web JSON et les cookies de session offrent tous deux une authentification sécurisée de l’utilisateur, mais ils présentent entre eux des différences importantes qui les rendent adaptés à différentes situations.

Mais maintenant, vous avez une compréhension de base de leurs principales différences afin de pouvoir décider de la façon dont vous devez aller de l’avant pour votre situation particulière.

Avez-vous décidé d’utiliser des jetons Web JSON ou des cookies de session pour votre projet ? Y a-t-il des domaines où vous n’êtes pas encore certain des différences entre eux ? N’hésitez pas à me faire part de vos réflexions dans les commentaires ci-dessous.


siddhy

Développeur web full stack depuis une 15aine d'année dans une agence web du sud de la France et Geek depuis toujours, l'apprentissage et le partage font parti intégrante de ma philosophie au même titre que l'évolution personnelle et la sagesse bouddhiste.

4 commentaires

Sam · 1 août 2019 à 10 h 16 min

L’avantage de JWT réside dans le fait qu’il est possible d’éviter de maintenir des sessions avec un bd (redis ou autre). Le mécanisme de signature par cryptographie valide à chaque fois la fiabilité des informations de session. Plus besoin de redis ou autre 🙂

Laurent · 10 août 2019 à 16 h 20 min

Salut et merci pour cet article.
Je débute en de web et je suis en train de me perdre dans toutes les histoires de sécurité des utilisateurs.
J’ai essayé les JWT et ils n’ont l’air pas mal, je les utilise justement dans le site que je suis en train de développer pour me former.
Par contre pour des raisons de sécurité, il est dit de stocker le JWT dans un cookie en httponly et secure et non en Storage Session ou Storage Local. (ce que je ne fais pas à l’heure actuelle)
Si je fais ainsi, je rencontre donc les problèmes lier aux cookies de session non ? Du moins au moins pour la taille que je peux stocker et sur le fait qu’il ne fonctionne que sur un seul domaine ou sur ses sous-domaines ?

    siddhy · 10 août 2019 à 18 h 23 min

    Salut et merci pour ton commentaire 🙂
    Les cookies de session sont en effet accessible uniquement sur le domaine sur lequel ils ont été créés. Pour le reste ça dépend vraiment de ce que tu veux stocker et pour quels raison. Il faut de toutes manière plutôt stocker des tokens plutôt que des informations critiques. Mais difficile de pouvoir être précis avec si peu d’infos 🙂

      Laurent · 10 août 2019 à 18 h 56 min

      Avec plaisir, c’est normal d’encourager les personnes qui prennent le temps d’expliquer au novice du web comme moi xD.
      Pour les informations stockées, généralement dans un token on stocke le nom d’utilisateur (ou le mail) ainsi que ses rôles. (si je ne dis pas de bêtises).
      Ce token est envoyé au front une fois l’authentification de l’utilisateur réussi dans le back.
      Mais une fois dans le front il y a plusieurs possibilités pour le “stoker”.
      Soit le stockage de session, soit le stockage local ou les cookies (pour les plus répandus).
      Les deux premiers ont des soucis de sécurité XSS à cause des scriptes Javascript et le dernier un problème de sécurité CSRF à moins que celui-ci sois en httponly et secure.
      Pour ça que j’ai vu que généralement qu’on préconise la sauvegarde du token et donc des informations qu’il contient dans un cookie en Httponly et sécurisé.
      Mais si je fais ainsi, je suppose que je me restreins donc aux “problèmes” lier aux cookies.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *