Discussion :

[Badshade23]

Bonjour tout le monde,
Dans un projet personnel, je crée un site web.
Le back est en Java avec l'utilisation de Spring et le front est en Angular.
J'arrive au moment fatidique où je dois gérer la création des utilisateurs ainsi que leurs connexions ^^.
Alors arrive un long moment de chercher dans tous les sens ^^.
J'ai fini par commencer à le faire via JWT et Spring sécurité.
À ça près tout ce passe bien, mais je tombe sur un problème. Après lecture d'innombrables blogs, il revient souvent que pour un gage de sécurité, il vaut mieux stocker le JWT dans un cookie en httponly et secure.
Le problème, c'est que pour l'instant je le stocke en Storage Session :

Code :

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

1
2
3
4
 public saveToken(token: string) {
    window.sessionStorage.removeItem(TOKEN_KEY);
    window.sessionStorage.setItem(TOKEN_KEY, token);
  }

J'ai regardé de nombreux codes et apparemment, il faut que le serveur une fois la connexion validée envoie au front le cookie et que celui-ci le stocke ou quelque chose comme ça.
Débutant dans la programmation web et apprenant tout en autodidacte, j'avoue que je me perds un peu dans tout ça.
J'aimerais avec des explications sur tout ceci et si vous avez des exemples en plus ça serai parfait ^^.
Merci d'avance et bonne journée !

[kevin254kl]

Salut,

Ce n'est pas propre à java mais aux webservices en général.
-Tu te connecte avec ton login et mot de passe
- Le serveur dit ok tiens un token jwt
- Tu fais une requête pour demander les produit avec le token
- le serveur regarde si ton token existe en base si oui c'est que tu es bien authentifié sinon non.

Tu peux pour la sécurité réduire le temps de validité de ton token avant qu'il expire.

[Badshade23]

Oui je comprend le principe, c'est la sauvegarde en cookie ou j'ai du mal.
Je sais que tout les langages fonctionne ainsi enfin si ils utilisent les tokens.
C'est plus la partie sauvegarde de celui-ci. Cookie...

[kevin254kl]

y'a un projet tu peux t'en inspirer https://github.com/mrin9/Angular-SpringBoot-REST-JWT je pense que tu dois utiliser le localstorage avec angular pour le cookie crypté.

[Badshade23]

Merci pour ta réponse après si je créais un cookie sécurisé, il faut que je le mette en httponly, du coup si je ne dis pas de bêtise il peut être créé et lu uniquement par le backend non ?
D'ailleurs, si c'est le cas, je ne sais pas comment mon front connaîtra les rôles et autres informations de l'utilisateur une fois celui-ci connecté.
Il passe des informations dans l'head des réponses ? Je n'arrive pas à trouver des cours/exemples sur le net s'est assez compliqué .
Pour la partie Web Storage (localStorage/sessionStorage) la plupart des sites de sécurité disent que c'est une mauvaise idée à cause des attaques. (le Web Storage (localStorage/sessionStorage) est accessible via JavaScript sur le même domaine. Cela signifie que tout JavaScript en cours d'exécution sur votre site aura accès au stockage Web et, de ce fait, peut être vulnérable aux attaques de script intersite (XSS) ).
Une des sources : https://stackoverflow.com/questions/...e-with-reactjs.

[keokaz]

Salut,

j'ai mis un tuto qui explique l'échange en jwt (pour y accéder il faut cliquer sur le buton vert , connexion anonyme).
https://ohkod.fr/moodle/mod/page/view.php?id=234

si cela peut t'aider à comprendre.

[Badshade23]

Merci keokaz pour le partage de ton tuto :-).
Ça fait toujours plaisir que des personnes partagent leurs connaissances ;-) .
J'ai regardé un peut ton code et j'ai vu que toi aussi tu stockais ton token en

Code :

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

 localStorage.setItem('token',jwt);

localStorage dans ton service

Code :

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

AuthenticationService

.
Une raison de ce choix ?
Que penses-tu du niveau de sécurité apporté par ce style de stockage (local ou session) par rapport aux cookies en httponly secure ?

[keokaz]

Si tu stocke le jwt dans un local storage tu n'a pas besoin d'écrire du code pour envoyé ce cookie "HttpOnly"(+ sécure pour le https).
si tu souhaite réutilisé ce cookie par une autre application je pense que tu ne peux pas le faire.
les cookie pour la sécurisé ne peut être utilisé que sur le domaine qui à été créer.
pour chaque requête, le navigateur envoie ce cookie , il y donc risque de CSRF

[Badshade23]

Oui, que ce soit en cookie ou en local Storage/SessionStorage il peut toujours avoir des risques de sécurité.
Ça reste un grand débat sur le net "où stocker le jeton JWT".
Il y a un très bon article sur le sujet https://blog.angular-university.io/a...uthentication/.
Au final, je tourne toujours autour du pot ...
J'ai regardé sur quelques sites basiques où étaient stockés leurs tokens. Si je ne dis pas de bêtise des sites telle que Facebook, leboncoin, amazone stocke leurs tokens grâce aux cookies.
Au final, je n'ai trouvé que peu de sites qui les stockent via le local storage.
Travaillant en autodidacte et non dans une entreprise pour ce projet, je ne connais pas la "bonne façon de faire".
La plupart des tutoriels sur Internet travaillant en back Spring et front Angular stockent les informations en local et non cookies.

[keokaz]

https://website.simplx.fr/blog/2016/...wt-et-cookies/

Comme indiqué précédemment, l’utilisation d’un Cookie entraîne le renvoi automatique par le navigateur à chaque requête, suivant la taille du Cookie cela peut être consommateur de bande passante (rien de grave à notre époque mais il faut le savoir). Néanmoins le Cookie est limité en taille (4ko), donc suivant la quantité d’information que vous souhaitez stocker, il faudra peut être vous tourner vers le web storage du navigateur, dont le contenu n’est jamais partagé avec le serveur, et qui a une limite de taille supérieure à 5 Mo.

Les Cookies sont en effet protégés des attaques XSS, nous l’avons vu avec le flag HttpOnly qui empêche l’accès via le javascript du domaine, mais ils sont sensibles à un autre type d’attaque : Cross-site request forgery (CSRF).
CSRF est une attaque au cours de laquelle un site internet malicieux cherche à se faire passer pour le domaine qui est à l’origine du Cookie, et ainsi forcer le navigateur à lui envoyer ce Cookie de manière totalement transparente, à votre insu. Car comme vous le savez désormais (on ne le répétera jamais assez), le navigateur envoie automatiquement le Cookie au serveur, s’il détecte que le Cookie est lié au domaine de ce site.

[Badshade23]

Oui, j'avais lu cet article aussi ^^.
Ici aussi, il met en avant l'utilisation d'un cookie en Httponly, c'est ce qu'il conseille d'ailleurs.

Les tokens JWT sont un excellent moyen de communication, ils permettent d’échanger entre un serveur et différentes applications clientes des informations d’utilisateur et de rôles de manière stateless. Ils sont signés et cryptés pour éviter d’être modifiés côté client, mais attention à l’endroit où vous décidez de les stocker! Nous vous recommandons vraiment d’utiliser les Cookies HttpOnly pour le transmettre, couplé au mécanisme de contrôle de token xsrf, vous serez protégés de manière efficace contre les attaques XSS (car HTML 5 Web Storage est vulnérable et le XSS bien plus fréquent que les attaques CSRF).

Par contre si le serveur sait à qui il a affaire je ne vois pas comment le client (Angular ici) connaît l'utilisateur ? Et par exemple s'il est admin dégrisent des menus. Le client doit à un moment ou à un autre connaître les droits de l’utilisateur connecté.
Donc stocker en local storage ses permissions. Car si je ne dis pas de bêtise comme il est indiqué dans l'article en "httponly" le client ne peut pas accéder aux informations que contient le cookie. Seul le serveur y a accès. Donc seul le serveur connaît le JWT. Le client n'a donc pas accès aux droits de celui-ci ni aux autres informations que pourrait contenir le JWT.
Décidément, cette partie est la plus complexe à maîtriser enfin de mon avis ^^.

[keokaz]

Quand je développe avec spring boot, je désactive le csrf, je ne donne pas la possiblité au serveur d'utiliser les formulaires qui utilise csrf, cela fait une chose de moins à s'occuper ...:

Code java :

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

1
2
3
4
 
  protected void configure(HttpSecurity http) throws Exception {
    System.out.println("==> csrf dispabled");
    http.csrf().disable();// genere erreur 403

Le jwt est une clés qui est déposer dans ton client qui peut être dupliqué dans plusieurs client(par exemple récupérer ce jwt et le mettre dans ton téléphone).
ce jwt à été signé par le serveur, en https ce jwt n'est pas lisible quand il se balade dans la nature, quand il arrive sur le serveur il ouvre ce jwt et test s'il est valide, en cas de modification
d'un seul caractère ou mettre role = admin, ce jwt ne sera pas valide, seul le serveur (ou les serveurs) qui possède la clés privé peut valider ce jwt.

avec un cookie je pense pas qu'on puisse faire du load balancing
avec du jwt oui mais là c'est une autre histoire (si on souhaite scallé son application). Si tu n'a que un seul client et un seul serveur, reste avec les cookies.

[Badshade23]

Ah ok donc si j'utilise mon site en HTTPS le JWT ne sera pas lisible par les utilisateurs ?
Il sera quand même accessible si l'utilisateur utilise les "outils de développement" de son navigateur et qu'il va dans la partie Stockage non ?
J'ai trouvé ce site qui "déchiffre" les JWT https://jwt.io/ et ça sans connaitre la clef secrète .
Je sais que l'encodage du JWT est basique "HS256, RS512..." mais pour déchiffrer un JWT il ne faut pas la clef secrète que contient le serveur ?
Car si ce n'est pas le cas (ce que j'en doute, mais bon...) l'utilisateur n'a qu'à copier le JWT qu'il récupère via son navigateur le colle sur le site puis change ses rôles avant de le recopier manuellement dans son local Storage.
Et du coup, ses droits changent.
Ça me parait abairant, mais je me suis déjà amusé à changer des valeurs du local storage à la main donc ...
C'est cette partie du local storage qui me "chagrine" un peu. On peut voir facilement ce qu'il contient et on peut le modifier avec autant de simplicité.
Le front après (ici mon code en Angular) va chercher des valeurs dans celui-ci et récupère des données qui ont été modifier par l'utilisateur donc des données falsifiées.
Je ne peux pas être sur à 100% que les données non pas étaient modifiées par un utilisateur malveillant.
Dans beaucoup de tutoriel on voit les personnes stocker les rôles en clair dans le local storage ce qui devient du coup complètement absurde, car l'utilisateur a juste à changer l'invite" en "admin" pour que le front le prenne pour un admin .

[keokaz]

[Badshade23]

Au top la vidéo, je ne l'avais pas trouvée celle-ci ^^.
Au final, c'est relativement simple, je me sens un peu bête XD.
Par contre pour une bonne vérification, le back doit vérifier le token à chaque requête de l'utilisateur, ça c'est relativement simple c'est ce que je fais déjà. Mais le front aussi non ? Pour vérifier justement les différents accès aux différentes pages.
Pour la vérification de l'expiration ça ne pose pas de problème en utilisant une librairie qui lie le token stocker, mais pour la signature mon front devra connaître mon secret pour la vérifier.
Est-ce dangereux de stocker sa signature dans le front . Toujours le même problème si les utilisateurs réussissent à mettre la main dessus ...
https://stackoverflow.com/questions/...dation-angular

[keokaz]

Je pense que tant que ton cléf privé ne se balade pas dans le front c'est inexploitable, si c'est pas suffisant , peut être que rajouter de l'encodage et décodage pour rendre l'information non compréhensible par une personne .

Code :

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

1
2
3
4
5
6
 
{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

mettre ceci à la place:

Code :

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

1
2
3
4
5
6
 
{
  "sub": "1234567890",
  "b068931cc450442b63f5b3d276ea4297": "4c2a904bafba06591225113ad17b5cec",
  "7d0db380a5b95a8ba1da0bca241abda1": 1516239022
}

[Badshade23]

J'ai bien réfléchi à tout ça et l’idée que tu as d'encodage du JWT côté front ne résout pas forcement le problème car pour le décoder et récupérer les rôles de l'utilisateur son nom ... mon front aura besoin du secret.
Donc on revient au problème que le front possède une clef secrète qui peut être récupérée et on retombe sur le problème d'avant.
Sinon j'ai trouvé une autre solution qui consiste à utiliser une clef privée et une clef publique (que j'ai généré via Openssl) en encodant le JWT en RS256. Comme ça seul mon serveur qui génère les tokens connaît la clef privée qui permet de signer et créer mes tokens. Ma clef publique elle peut-être connut par tout le monde, car son seul rôle est de valider le token en aucun cas elle peut en créer un. Comme ça, dans l'idée, mon front peut à n'importe quel moment vérifier si le token qu'il contient a était modifié et si c'est le cas le supprimer.
J'ai donc effectué toutes les modifications sur mon serveur et j'envoie ensuite mon token plus la clef publique à mon front.
Le problème, c'est que je n'ai pas trouvé de librairie Angular qui permettait de vérifier si le token était bon avec ma clef publique. J'ai donc sollicité encore une fois l'aide de la communauté de "Développez com" et en expliquant mon problème, on m'a clairement dit qu'il ne fallait pas que je stocke mon token en session/local storage, mais dans un cookie.

La bonne méthode c'est d'utiliser un header http Authorization de type Bearer. Cf OAuth2

https://www.developpez.net/forums/d2...d-jwt-angular/
J'ai donc tout laisser pour partir sur ce fameux OAuth2. Et je le trouve encore plus complexe que l'ancienne méthode xD.
Je suis donc preneur si des personnes ont déjà créer un système d’authentification en Spring avec Oauth2, conseils ...
Merci d'avance et je vous tiendrai au courant quand j'aurai ENFIN résolue le problème.

[keokaz]

j'ai vu une vidéo qui peut être intéressante:

D'autre ressource intéressant avec spring boot:

https://kelvinleong.github.io/authen...ntication.html

Code :

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

1
2
 
However, cookies based authentication is a very painful work when your applications scales up and you need to maintain the security of those connected sessions which is vulnerable to be hacked if messy management is conducted. Therefore, Jwts as a sessionless and light-weight auth service is embraced by many developers