Discussion :

[Badshade23]

Bonjour tout le monde, j'aurai une question :
Comment peut-on vérifier la signature d'un token JWT codé en rs256 (clef publique, clef privée) ?
Mon back-end génère le token et l'envoie au front qui le stocke en local Storage. J'aimerais donc vérifier la validité de la signature de mon token dans le front.
J'ai trouvé quelques librairies : https://www.npmjs.com/package/express-jwt ou encore https://www.npmjs.com/package/jsonwebtoken.
Mais les exemples sont pour NodeJS ce qui n'est pas mon cas ici.
Pour info mes clefs sont stockées dans deux fichiers : private_key.pem , public_key.pem.
Quelqu'un pour m'aider?

[Marco46]

Stocker le token dans le LocalStorage est une très mauvaise pratique. Ça rend ton token potentiellement vulnérable aux XSS.

Concernant la vérification de signature ce n'est pas au front de faire ça mais au backend.

Enfin pour vérifier une signature tu n'as besoin que de la clef publique. Donc si tu trouves de quoi vérifier la signature côté front, même si ça ne sert absolument à rien tu n'as besoin que d'exposer ta clef publique sur un endpoint public.

[Badshade23]

Merci pour ta réponse.
Quant au moyen de stockage j'ai vu de nombreux débats sur le net pour savoir s'il fallait un cookie et si oui, il faut qu'il soit en http only et secure ou en local/session storage.
Étant débutant dans ce domaine, si j'utilise un cookie pour stocker mon Token, celui-ci ne sera pas lisible par mon client car seule le serveur pourra le lire (si je ne dit pas de bêtises). Comment alors connaître les informations de celui-ci ? Ses droits par exemple ? Pour savoir si oui ou non je dois lui afficher le menu d'administration du site (en outre).
Selon ce que j'ai lu, le cookie aussi a des vulnérabilités (attaques CSRF).
Je vérifie déjà la signature avec ma clef public sur mon serveur à chacun requête des utilisateurs. Mon désire de vérifier aussi dans le front est dû au faite qu'un JWT stocké dans la Session/Local storage peut être modifié facilement, mais la signature ne sera du coup plus valide. Donc ça me permettra de savoir si l'utilisateur c'est rajouté par exemple des droits d'admin. Ce qui lui déverrouille des affichages dans le site (même si après ses requêtes seront rejetées par le serveur quand il contrôlera le jeton. Je veux empêcher ça bien avant).
Encore une fois je suis débutant dans ce domaine et j’apprends tout en autodidacte grâce à Internet (tuto, forum, vidéo...).
Je suis vraiment preneur de bon conseil quitte à tout recommencer, je préfère partir sur de bonnes bases.

[Marco46]

Merci pour ta réponse.
Quant au moyen de stockage j'ai vu de nombreux débats sur le net pour savoir s'il fallait un cookie et si oui, il faut qu'il soit en http only et secure ou en local/session storage.
Étant débutant dans ce domaine, si j'utilise un cookie pour stocker mon Token, celui-ci ne sera pas lisible par mon client car seule le serveur pourra le lire (si je ne dit pas de bêtises). Comment alors connaître les informations de celui-ci ? Ses droits par exemple ? Pour savoir si oui ou non je dois lui afficher le menu d'administration du site (en outre).
Selon ce que j'ai lu, le cookie aussi a des vulnérabilités (attaques CSRF).

La bonne méthode c'est d'utiliser un header http Authorization de type Bearer. Cf OAuth2. Avec ces 3 mots clefs tu devrais t'y retrouver.

Je vérifie déjà la signature avec ma clef public sur mon serveur à chacun requête des utilisateurs.

C'est ce qu'il faut faire, et vérifier que le token est toujours valide (session).

Et il faut également vérifier que l'utilisateur accède bien à des données qui lui appartiennent même si son token est valide.

Si par exemple tu as un endpoint /user-account/<userAccountId> il ne faut pas qu'un utilisateur même connecté avec un token valide puisse accéder au compte d'un autre utilisateur.

Mon désire de vérifier aussi dans le front est dû au faite qu'un JWT stocké dans la Session/Local storage peut être modifié facilement, mais la signature ne sera du coup plus valide. Donc ça me permettra de savoir si l'utilisateur c'est rajouté par exemple des droits d'admin. Ce qui lui déverrouille des affichages dans le site (même si après ses requêtes seront rejetées par le serveur quand il contrôlera le jeton. Je veux empêcher ça bien avant).

Ce contrôle ne sert à rien pour se protéger de l'utilisateur. L'utilisateur télécharge une page web qui exécute des scripts qui sont interprétés par le navigateur sur lequel il a un contrôle complet. Il lui suffit d'ouvrir les outils de dev et il fait ce qu'il veut.

Tant que les données sont protégées côté back il n'y a pas de soucis. L'utilisateur s'amuse à bidouiller les scripts pour afficher des vues auxquelles il n'est pas censé avoir accès ? C'est son problème s'il flingue son affichage. Ça ne pose pas de soucis tant que les données côté back ne lui sont pas transmises.

En termes plus simple, tu t'enquiquines pour rien il n'y a aucun problème de sécurité à ce niveau. En revanche garder le token dans le local storage ça ça ouvre des portes pour un attaquant tiers potentiel.

[Badshade23]

Merci pour ton éclaircissement. ^^

C'est ce qu'il faut faire, et vérifier que le token est toujours valide (session).
Et il faut également vérifier que l'utilisateur accède bien à des données qui lui appartiennent même si son token est valide.
Si par exemple tu as un endpoint /user-account/<userAccountId> il ne faut pas qu'un utilisateur même connecté avec un token valide puisse accéder au compte d'un autre utilisateur.

Pour cette partie-là, je comprends et c'est ce que je compte faire ou fais déjà.

Ce contrôle ne sert à rien pour se protéger de l'utilisateur. L'utilisateur télécharge une page web qui exécute des scripts qui sont interprétés par le navigateur sur lequel il a un contrôle complet. Il lui suffit d'ouvrir les outils de dev et il fait ce qu'il veut.

Tant que les données sont protégées côté back il n'y a pas de soucis. L'utilisateur s'amuse à bidouiller les scripts pour afficher des vues auxquelles il n'est pas censé avoir accès ? C'est son problème s'il flingue son affichage. Ça ne pose pas de soucis tant que les données côté back ne lui sont pas transmises.

En termes plus simple, tu t'enquiquines pour rien il n'y a aucun problème de sécurité à ce niveau.

Je pensais qu'il fallait un minimum empêcher l'utilisateur de modifier l'aspect visuel du site. Même si c'est vrai que celui-ci à juste a enlevé le "*ngIf" de la div pour qu'elle apparaît quoi qu'il arrive ce que je trouve un peu dommage.

En revanche garder le token dans le local storage ça ça ouvre des portes pour un attaquant tiers potentiel.

J'en suis conscient, via l'injection de script dans le navigateur si je ne dis pas de bêtises. Mais c'est étrange que la plupart des tutoriels (pour ne pas dire tous) utilisent cette technique pour stocker leur token .
Même si certain comme je l'ai dit plus haut mette en avant aussi le cookie en httponly et secure, mais on trouve que très peu d'exemples.

La bonne méthode c'est d'utiliser un header http Authorization de type Bearer. Cf OAuth2. Avec ces 3 mots clefs tu devrais t'y retrouver.

J'ai fait des recherches à ce sujet et je dois avouer que j'ai un peu de mal à comprendre le tout. J'ai compris le principe : (Serveur d'autorisation - Serveur de ressources)
Où pour autoriser une application à accéder aux ressources, l'utilisateur doit être validé auprès du serveur d'autorisation (serveur d'authentification) qui génère un token pour celui-ci qui indique ses droits.
Le serveur de ressources valide par la suite l’accès aux ressources via la signature du token et les échanges du token se font dans l'header du http du type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 Authorization: Bearer <token>

Mais l'après et un peu plus flou (Comme récupérer les informations dans le front une fois que le token est stocké dans un cookie, récupérer la clef public ...).
J'ai même vu des tutoriels qui permettent de se connecter à notre site via notre compte Facebook ou même Gmail.
J'ai trouvé un exemple qui utilise les techniques/framework avec lesquelles je travaillehttps://www.baeldung.com/rest-api-spring-oauth2-angular
Back : Spring boot avec security et donc maintenent OAuth2 suite à tes conseils
Front : Angular
Je suis en train de l'étudier sur mon temps libre, mais je suis toujours preneur de conseil/exemple qui pourrait améliorer ma compréhension. Où même si vous avez de bonnes adresses pour des cours ou autres .