Cookies: dans leur première version, un fichier texte avec un identifiant client unique et toutes les autres informations nécessaires sur le client (ex: rôles)
Les cookies sont des tuples key-valueadressés à l'origine pour conserver les données liées à l'activité du client. Cette conservation est ce que nous appelons l'état de session ou d' application . Fondamentalement, ils ont été conçus pour contenir l'état des applications Web; plus précisément, l'état côté client. (1)
Les cookies sont généralement définis par le serveur via des en-têtes de réponse ( Set-Cookie key=value). Cependant, ils peuvent également être définis par le client. Par exemple, par DOM ( document.cookie).
Une chose importante à savoir sur les cookies est qu'ils n'identifient pas les utilisateurs. Ils associent plutôt les données terna - client - serveur / chemin . (3)
Nous associons généralement les cookies aux fichiers, car pendant les premiers jours des navigateurs Web, ils devaient en quelque sorte persister les cookies, étant les fichiers le support le plus réalisable. Les navigateurs d'aujourd'hui stockent les cookies (entre autres) dans des stockages locaux (bases de données intégrées).
Session: seul l'identifiant client unique est envoyé dans un fichier (également appelé cookie), tout le reste est stocké sur le serveur.
Par session, je suppose que vous entendez les sessions serveur . Comme je l'ai commenté, les sessions peuvent également être implémentées côté client. La différence avec les sessions côté client est que les données sont stockées quelque part côté serveur. (2) Dans de tels scénarios, nous obtenons un identifiant de session; et nous l'obtenons sous forme de cookie. Sans l'ID de session, le serveur ne serait pas en mesure de corréler les demandes entrantes avec l'activité précédente du client. (3) Par exemple, l'utilisateur authentifié, le panier d'achat, etc.
Dans tous les cas, un ID de session n'identifie pas nécessairement un utilisateur. Il associe un état d'application spécifique à un client Web. Les sessions peuvent contenir ou non des données utilisateur.
Dans les applications distribuées, la session doit être sérialisable pour des raisons évidentes. S'ils sont stockés en mémoire, le stockage en mémoire (composant) doit être sérialisable. Une solution courante consiste à stocker des sessions dans des fichiers. Ou dans NoSQL DB comme Redis.
Concernant la sécurité. Les sessions côté serveur sont plus sûres que côté client. Les clients sont plus vulnérables aux menaces car les utilisateurs ne sont généralement pas conscients des nombreuses menaces auxquelles ils sont exposés. Du moins pas l'utilisateur régulier.
D'un autre côté, attaquer une infrastructure côté serveur n'est pas banal.
JWT: tout est stocké dans le token (qui pourrait également être stocké dans un fichier texte, également appelé cookie)
Pas vraiment. JWT stocke des données principalement liées à l'autorisation et à l'émetteur du token.
Bien qu'ils utilisent pour contenir l'ID utilisateur (sub), nous trouvons des JWT qui n'identifient pas les utilisateurs authentifiés. Par exemple, des jetons pour les sessions d'invités. Le contenu principal des JWT sont les revendications ; les éléments à vérifier par le processus d'autorisation.
Il est important de garder à l'esprit que les JWT ne sont pas des stockages mondiaux . La session ou l' état de l' application doit encore être stocké quelque part et géré indépendamment.
En ce qui concerne les JWT, ceux-ci sont souvent stockés sous forme de cookies, bien qu'ils puissent également être stockés dans des stockages locaux. De plus, la communauté OWASP considère que sessionStorage est le plus sécurisé pour les navigateurs Web. Cependant, cela dépend de la version du navigateur .
1: Le World Wide Web est censé être apatride. Si nous voulons créer des applications côté serveur sans état, les sessions doivent être stockées quelque part côté client.
2: Transformer l'application côté serveur en une application avec état .
3: Client en tant qu'application, pas en tant qu'utilisateur.
user_idpour un utilisateur connecté.Votre définition de cookie ne décrit pas vraiment ce qu'ils font. Un cookie est une paire clé-valeur définie via l'en-tête de réponse HTTP (
Set-Cookie) par le serveur et stockée par les clients qui les prennent en charge. Les cookies sont renvoyés avec chaque demande ultérieure (dans l'en-Cookietête) pour les demandes correspondant au schéma, à l'hôte, au chemin, https alors que le cookie n'a pas expiré. Vous pouvez stocker tout ce que vous voulez dans un cookie, et cela vous permet de prendre en charge l'état sur le protocole sans état de HTTP.Un exemple d'échange de cookies ressemble à ceci:
C'est à peu près juste. Une session est une donnée stockée côté serveur concernant la session actuelle d'un utilisateur. Pour que cela fonctionne dans un protocole sans état tel que HTTP, l'utilisateur doit envoyer son ID de session à chaque demande, afin que le serveur puisse récupérer la session appropriée pour l'utilisateur. L'identifiant de session est généralement stocké dans un cookie (voir ci-dessus). Ce n'est pas un cookie différent de tout autre cookie, les données ne sont que l'ID du serveur pour la session utilisateur.
C'est à peu près vrai. Tout est stocké dans le jeton. Le jeton peut être stocké dans un cookie (voir ci-dessus). Il s'agit d'une alternative aux sessions serveur, et cela fonctionne parce que le jeton est signé et vérifié par le serveur, il ne peut donc pas être modifié ou falsifié, et il est sûr de le stocker côté client.
la source