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-value
adressé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_id
pour un utilisateur connecté.