Super vidéo. J'ai quand même du mal à comprendre la hype autour de cette implementation. De mon humble experience, j'ai toujours eu besoin de faire au moins une requête en base ne serait-ce que pour avoir la dernière version de l'utilisateur, ou simplement update un datetime pour logguer sa dernière activité (et j'en passe). Mais en faisant la même chose avec JWT, son seul avantage est tout simplement annulé (ou presque). Et si j'ajoute à ça le fait qu'une fuite de la clé secrète permet un accès total à l'intégralité des comptes utilisateurs, et qu'il n'y a pas vraiment de possibilité évidente de "bloquer" une token créée avant son expiration, je ne peu que me questionner sur son intérêt. Et je trouve son utilisation encore moins justifiée via socket, car contrairement à une API http classique qui elle est "stateless", le socket lui est "statefull", donc une seule requête en base est nécessaire à l'ouverture du socket pour gérer une authentification sur toute sa durée (contre une par requête sur une API http). Ce qui rend la charge sur la BDD beaucoup moins importante par socket. Bref, comme tu l'a très bien dit dans ta vidéo, je pense que JWT n'est pas du tout adapté à tout les projets et qu'il ne faut surtout pas faire l'erreur de l'implementer seulement parce que c'est cool et sexy. En revanche, le simple fait de parler d'authentification (quelle que soit son type) sur socket dans cette série de video est une très bonne idée (car souvent oublié).
Une amélioration serait d'utiliser JWT avec private/public key. Dans ce cas, si on devait séparer websocket du serveur d'auth le websocket possèderait la clé publique et le serveur d'auth possèderait la clé privé. Dans le cas de la vidéo, le serveur d'auth et le websocket se partage le "secret" ce qui augmente les risques puisque ce dernier est dupliqué à deux endroits
Jai utiliser cette explication pour mon collegue de hong kong en traduisant rapidement il a compris l'enjeu et le pourquoi on utilise jwt pour soulager le auth server. Thanks Bro!
merci pour la video. enfin j ai compris JWT ! dans le workflow a 7'20 , tu indiques que le websocket peut a partir de sa cle privee verifier la signature du token. on traite donc le cas de l algo RS; mais quid de l algo HS256 ou il n y pas de cle public/prive mais une cle secrete ? autre question est ce que les tokens sont cryptes ou bien juste encodes lorsqu ils sont echanges ? thanks !
Hello merci pour la vidéo. Donc si j'ai bien compris tout repose sur la clef privé. Si par exemple un utilisateur était amené a récupérer la clef privé, il pourrait modifier le token et se faire passer pour un administrateur par exemple?
Explications claires et concises. Merci !
Bravo, c'est rare d'avoir des informations claires en français, merci !
Top, clair et concis, j'attends la partie 2 avec impatience. Merci Jo!
La seconde partie arrive demain même heure ;)
c'est clair, simple, mieux qu'un prof,heureusement que tu existe hhhhh merci pour toutes tes videos (y) et bonne continuation
Pourras-tu faire un tutoriel sur la sécurisation des API à l'aide de oauth2 ? Merci pour ton travail au quotidien !
Très bien expliqué
Super vidéo, cela dit j'aurais bien aimé que tu expliques la clef public et la clef privée
Tres bon tuto et très clair
Merci beaucoup.
très pédagogique, très clair. merci et bravo.
Bon courage mon amie
Merci Grafikart
Enfin le JWT ! un grand merci ;) pour ce taff !
Super vidéo.
J'ai quand même du mal à comprendre la hype autour de cette implementation. De mon humble experience, j'ai toujours eu besoin de faire au moins une requête en base ne serait-ce que pour avoir la dernière version de l'utilisateur, ou simplement update un datetime pour logguer sa dernière activité (et j'en passe). Mais en faisant la même chose avec JWT, son seul avantage est tout simplement annulé (ou presque). Et si j'ajoute à ça le fait qu'une fuite de la clé secrète permet un accès total à l'intégralité des comptes utilisateurs, et qu'il n'y a pas vraiment de possibilité évidente de "bloquer" une token créée avant son expiration, je ne peu que me questionner sur son intérêt.
Et je trouve son utilisation encore moins justifiée via socket, car contrairement à une API http classique qui elle est "stateless", le socket lui est "statefull", donc une seule requête en base est nécessaire à l'ouverture du socket pour gérer une authentification sur toute sa durée (contre une par requête sur une API http). Ce qui rend la charge sur la BDD beaucoup moins importante par socket.
Bref, comme tu l'a très bien dit dans ta vidéo, je pense que JWT n'est pas du tout adapté à tout les projets et qu'il ne faut surtout pas faire l'erreur de l'implementer seulement parce que c'est cool et sexy.
En revanche, le simple fait de parler d'authentification (quelle que soit son type) sur socket dans cette série de video est une très bonne idée (car souvent oublié).
Une amélioration serait d'utiliser JWT avec private/public key. Dans ce cas, si on devait séparer websocket du serveur d'auth le websocket possèderait la clé publique et le serveur d'auth possèderait la clé privé. Dans le cas de la vidéo, le serveur d'auth et le websocket se partage le "secret" ce qui augmente les risques puisque ce dernier est dupliqué à deux endroits
Jai utiliser cette explication pour mon collegue de hong kong en traduisant rapidement il a compris l'enjeu et le pourquoi on utilise jwt pour soulager le auth server. Thanks Bro!
Et pour un système de sécurité plus poussé tu conseille quoi à la place du jwt ?MERCI 👍
Merci
merci pour la video. enfin j ai compris JWT ! dans le workflow a 7'20 , tu indiques que le websocket peut a partir de sa cle privee verifier la signature du token. on traite donc le cas de l algo RS; mais quid de l algo HS256 ou il n y pas de cle public/prive mais une cle secrete ? autre question est ce que les tokens sont cryptes ou bien juste encodes lorsqu ils sont echanges ? thanks !
first!
Nice! ce tuto me rappelle un le WebRTC et celui du chat instantanée avec socket.IO.
Merci pour la présentation!
un bon tuto!
merci bcp bcp
Excellente vidéo merci !
Hello merci pour la vidéo. Donc si j'ai bien compris tout repose sur la clef privé. Si par exemple un utilisateur était amené a récupérer la clef privé, il pourrait modifier le token et se faire passer pour un administrateur par exemple?
Super clair! Merci :)
Excellent !
Comment faire avec jwt sur portable je reste bloqué
Quelle est la différence avec passport ?. a quel moment utilisé jwt , passport ou une authentification classique svp?
Dans le cas de l'algorithme HS256, comment fait-on pour savoir si le token provient bel et bien du serveur d'authentification ?
qu'est-ce vous avez utiliser pour les diagrammes de sequences? plutot sympa comme rendu
Gravit designer, c'est un outil gratuit qui est plutôt générique mais qui fournit des librairies graphiques qui peuvent servir
Merci!!!!
thnx
merci