J'ai lu quelques articles sur "JWT vs Cookie" mais ils m'ont seulement rendu plus confus ...

1. Je veux des éclaircissements , quand les gens parlent d '"authentification basée sur des jetons vs cookies", les cookies ici se réfèrent simplement aux cookies de session ? Je crois comprendre que le cookie est comme un support , il peut être utilisé pour implémenter une authentification basée sur un jeton (stocker quelque chose qui peut identifier l'utilisateur connecté du côté client ) ou une authentification basée sur la session (stocker une constante du côté client qui correspond aux informations de session côté serveur )

2. Pourquoi avons-nous besoin d' un jeton Web JSON ? J'utilisais le cookie standard pour implémenter l'authentification basée sur les jetons ( sans utiliser l'identifiant de session, ni utiliser la mémoire du serveur ni le stockage de fichiers ) :,Set-Cookie: user=innocent; preferred-color=azure et la seule différence que j'ai observée est que JWT contient à la fois la charge utile et la signature ... alors que vous pouvez choisir entre un cookie signé ou en clair pour l'en-tête http. À mon avis, le cookie signé ( cookie:'time=s%3A1464743488946.WvSJxbCspOG3aiGi4zCMMR9yBdvS%2B6Ob2f3OG6%2FYCJM') est plus efficace en termes d'espace, le seul inconvénient est que le client ne peut pas lire le jeton, seul le serveur peut ... mais je pense que c'est bien parce que tout comme la revendication dans JWT est facultative, ce n'est pas nécessaire pour le jeton de être significatif

La plus grande différence entre les jetons de support et les cookies est que le navigateur enverra automatiquement des cookies , où les jetons de support doivent être ajoutés explicitement à la requête HTTP.

Cette fonctionnalité fait des cookies un bon moyen de sécuriser les sites Web, où un utilisateur se connecte et navigue entre les pages à l'aide de liens.

Le navigateur qui envoie automatiquement des cookies présente également un gros inconvénient, à savoir les attaques CSRF . Lors d'une attaque CSRF, un site Web malveillant tire parti du fait que votre navigateur attachera automatiquement des cookies d'authentification aux demandes adressées à ce domaine et incitera votre navigateur à exécuter une demande.

Supposons que le site Web à l' adresse https://www.example.com permette aux utilisateurs authentifiés de modifier leurs mots de passe en POSTutilisant le nouveau mot de passe https://www.example.com/changepassword sans que le nom d'utilisateur ou l'ancien mot de passe ne soit affiché.

Si vous êtes toujours connecté à ce site Web lorsque vous visitez un site Web malveillant qui charge une page dans votre navigateur qui déclenche un POST à ​​cette adresse, votre navigateur attachera fidèlement les cookies d'authentification, permettant à l'attaquant de modifier votre mot de passe.

Les cookies peuvent également être utilisés pour protéger les services Web, mais de nos jours, les jetons porteurs sont le plus souvent utilisés. Si vous utilisez des cookies pour protéger votre service Web, ce service doit vivre sur le domaine pour lequel les cookies d'authentification sont définis, car la politique de même origine n'enverra pas de cookies à un autre domaine.

En outre, les cookies rendent plus difficile pour les applications non basées sur un navigateur (comme les applications mobiles vers tablettes) d'utiliser votre API.

Aperçu

Ce que vous demandez, c'est la différence entre les cookies et les jetons de support pour l'envoi de jetons Web JSON (JWT) du client au serveur.

Les cookies et les jetons porteurs envoient des données.

Une différence est que les cookies servent à envoyer et à stocker des données arbitraires, tandis que les jetons de support sont spécifiquement destinés à l'envoi de données d'autorisation.

Ces données sont souvent encodées en JWT.

Biscuit

Un cookie est une paire nom-valeur, qui est stockée dans un navigateur Web, et qui a une date d'expiration et un domaine associé.

Nous stockons les cookies dans un navigateur Web avec JavaScript ou avec un en-tête de réponse HTTP.

document.cookie = 'my_cookie_name=my_cookie_value'   // JavaScript
Set-Cookie: my_cookie_name=my_cookie_value           // HTTP Response Header

Le navigateur Web envoie automatiquement des cookies à chaque demande au domaine du cookie.

GET http://www.bigfont.ca
Cookie: my_cookie_name=my_cookie_value               // HTTP Request Header

Jeton porteur

Un jeton de support est une valeur qui entre dans l'en- Authorizationtête de toute requête HTTP. Il n'est automatiquement stocké nulle part, il n'a pas de date d'expiration et aucun domaine associé. C'est juste une valeur. Nous stockons manuellement cette valeur dans nos clients et ajoutons manuellement cette valeur à l'en-tête d'autorisation HTTP.

GET http://www.bigfont.ca
Authorization: Bearer my_bearer_token_value          // HTTP Request Header

Authentification basée sur JWT et Token

Lorsque nous procédons à une authentification basée sur des jetons, telle que OpenID, OAuth ou OpenID Connect, nous recevons un access_token (et parfois id_token) d'une autorité de confiance. Habituellement, nous voulons le stocker et l'envoyer avec les requêtes HTTP pour les ressources protégées. Comment fait-on cela?

L'option 1 consiste à stocker le (s) jeton (s) dans un cookie. Cela gère le stockage et envoie également automatiquement le (s) jeton (s) au serveur dans l'en- Cookietête de chaque demande. Le serveur analyse ensuite le cookie, vérifie le (s) jeton (s) et répond en conséquence.

Une autre option consiste à stocker le jeton dans le stockage local / de session, puis à définir manuellement l'en- Authorizationtête de chaque demande. Dans ce cas, le serveur lit l'en-tête et procède comme avec un cookie.

Il vaut la peine de lire les RFC liés pour en savoir plus.

En plus de ce que MvdD a dit à propos des cookies envoyés automatiquement:

1. Un cookie peut être un support, mais sa fonction la plus importante est la façon dont il interagit avec le navigateur. Les cookies sont définis par le serveur et envoyés dans les demandes de manière très spécifique. JWT en revanche est exclusivement un médium, c'est une affirmation de certains faits dans une structure particulière. Si vous le souhaitez, vous pouvez mettre un JWT comme cookie d'authentification. Lorsque vous lisez des articles les comparant, ils parlent généralement de l'utilisation d'un JWT envoyé en tant que jeton de support par un code frontal par rapport à un cookie d'authentification qui correspond à une session en cache ou à des données utilisateur sur le back-end.
2. JWT offre de nombreuses fonctionnalités et les met dans une norme afin qu'elles puissent être utilisées entre les parties. Un JWT peut agir comme une affirmation signée de certains faits dans de nombreux endroits différents. Un cookie, quelles que soient les données que vous y mettez ou si vous le signez, n'a vraiment de sens à utiliser qu'entre un navigateur et un back-end spécifique. JWT peut être utilisé du navigateur au back-end, entre les back-ends contrôlés par différentes parties (OpenId Connect en est un exemple), ou dans les services back-end d'une partie. En ce qui concerne votre exemple spécifique de vos cookies signés, vous pouvez probablement obtenir les mêmes fonctions ("ne pas utiliser l'identifiant de session, ne pas utiliser la mémoire du serveur ou le stockage de fichiers") que JWT dans ce cas d'utilisation, mais vous perdez sur les bibliothèques et l'examen par les pairs de la norme, en plus des questions CSRF évoquées dans l'autre réponse.

En résumé: les articles que vous lisez comparent probablement JWT en tant que jeton de support à un cookie d'authentification à des fins d'authentification du navigateur au serveur. Mais JWT peut faire beaucoup plus, il apporte une standardisation et des fonctionnalités à utiliser en dehors du cas d'utilisation auquel vous pensez probablement.

Bien que les cookies puissent augmenter le risque d'attaques CSRF en raison de leur envoi automatique avec les demandes, ils peuvent réduire le risque d'attaques XSS lorsque l' HttpOnlyindicateur est défini, car tout script injecté dans la page ne pourra pas lire le cookie.

CSRF: un utilisateur clique sur un lien (ou visualise des images) sur le site d'un attaquant, ce qui amène le navigateur à envoyer une requête au site de la victime. Si la victime utilise des cookies, le navigateur inclura automatiquement le cookie dans la requête, et si la requête GET peut provoquer des actions non en lecture seule, le site victime est vulnérable à l'attaque.

XSS: un attaquant intègre un script dans le site victime (le site victime n'est vulnérable que si les entrées ne sont pas correctement nettoyées), et le script de l'attaquant peut faire tout ce que javascript est autorisé à faire sur la page. Si vous stockez des jetons JWT dans le stockage local, le script de l'attaquant pourrait lire ces jetons et également envoyer ces jetons à un serveur qu'il contrôle. Si vous utilisez des cookies avec le HttpOnlydrapeau, le script de l'attaquant ne pourra pas lire votre cookie pour commencer. Cela dit, le script qu'ils ont injecté avec succès sera toujours en mesure de faire tout ce que javascript peut faire, vous êtes donc toujours au jet d'OMI (c'est-à-dire qu'ils ne pourront peut-être pas lire le cookie pour l'envoyer à leur propre serveur pour une utilisation ultérieure , ils peuvent envoyer des requêtes au site vicitim en utilisant XHR, qui inclura de toute façon le cookie).

Réf - Besoin de jeton Web JSON

Biscuits

En cas de cookies, une fois que l'utilisateur a été authentifié, le serveur Gmail créera un identifiant de session unique. Correspondant à cet identifiant de session, il stockera en mémoire toutes les informations utilisateur nécessaires au serveur Gmail pour reconnaître l'utilisateur et lui permettre d'effectuer des opérations.
Aussi, pour toutes les demandes et réponses ultérieures, cet identifiant de session sera également transmis. Alors maintenant, lorsque le serveur reçoit une demande, il vérifie l'ID de session. L'utilisation de cet identifiant de session vérifiera s'il existe des informations correspondantes. Il permettra ensuite à l'utilisateur d'accéder à la ressource et de renvoyer la réponse avec l'identifiant de session.

Inconvénients des cookies

• Les cookies / l'identifiant de session ne sont pas autonomes. C'est un jeton de référence. Lors de chaque validation, le serveur Gmail doit récupérer les informations qui lui correspondent.
• Ne convient pas à l'architecture de microservices impliquant plusieurs API et serveurs

JWT

• JWT est autonome. C'est un jeton de valeur. Ainsi lors de chaque validation le serveur Gmail n'a pas besoin de récupérer les informations qui lui correspondent.
• Il est signé numériquement, donc si quelqu'un le modifie, le serveur le saura
• Il est le plus adapté à l'architecture de microservices
• Il présente d'autres avantages comme la spécification du délai d'expiration.