J'ai une API backend accessible uniquement via l'authentification. Ceci est offert via JSON WEB Token (JWT), une fois qu'une paire d'informations d'identification correcte est donnée.
Maintenant, je développe maintenant le frontend pour mon application à l'aide d'angular 9. Le login est géré par un Après la première demande au serveur (la demande de connexion), j'ai défini un Intercepteur Pour insérer la valeur du JWT dans la demande suivante à l'API. Maintenant, l'un de mes collègues dit que nous devons stocker la valeur de jeton à l'intérieur du cookie sur le navigateur.
Pour moi, je ne trouve aucune raison de faire cela: pourquoi stocker des informations d'identification dans un navigateur si nous avons déjà notre intercepteur pour authentifier les demandes? auth.service qui renvoie un JWT si les informations d'identification correctes sont données.
3 Réponses :
Il existe donc plusieurs façons de répondre à cette question:
Tout est tombé à la sécurité un peu. Donc, si vous stockez votre jeton JWT (qui ne doit toujours être pas de données de longue durée) dans localStorage / sessionStorage ou un cookie.
La différence est que localStorage / SessionStorage est accessible à partir de chaque fichier JavaScript de votre domaine, qui peut créer un problème de sécurité de script de site inter-sites (XSS) s'il est mal manipulé. Pour vous prévenir contre XSS, je conseillerais de vous échapper et de coder toutes les données non soignées.
Donc, en fait toute la communication qui passe de votre frontend à votre backend. Dans le monde du spa, il s'agit d'une norme de ne jamais pousser les données provenant de votre frontend et de le vérifier toujours dans le backend.
Pour les cookies Lorsque vous utilisez httponly, ces cookies ne peuvent pas être accessibles via JavaScript. Assurez-vous également de définir le drapeau sécurisé, ce cookie ne peut donc être envoyé que sur HTTPS (No-Breaker). Bien sûr, les cookies ont également leurs problèmes de sécurité, vous devez vous empêcher de faire face à la demande de la demande sur le site interrompue (CSRF). Si vous voulez en savoir plus à ce sujet, lisez sur l'ajout d'un jeton XSRF dans votre revendication JWT.
En bref, je conseillerais également à aller avec des cookies au lieu de localStorage / sessionStorage.
Certaines distances se lisent:
Le jeton JWT Il est utilisé pour permettre à l'application angulaire de faire des demandes HTTP uniquement autorisées pour l'utilisateur authentifié.
À cause de cela, vous aurez besoin du JWT une fois que l'utilisateur a été authentifié.
Ensuite, l'intercepteur est utile pour voir si une requête HTTP a la JWT avant de ne pas être exécutée et si elle ne l'ajoute pas à la requête HTTP.
Maintenant, la question est la suivante: où j'ai stocké le JWT dans l'application afin de ne pas demander l'authentification à l'utilisateur à chaque fois que vous devez effectuer une demande HTTP au serveur Backend?
Là, vous avez deux options: local / session Stockage (non recommandé à cause de la sécurité) et des cookies.
La plupart des cours angulaires / Web ou des blogs montrent des exemples à l'aide du stockage local / session, mais ce n'est pas recommandé en raison de problèmes de sécurité. Ici c'est une belle explication à ce sujet: https://dev.to/rdegges/plase-stop-utilisation- local-stockage-1i04
À cause de cela, le meilleur endroit pour stocker le JWT est le cookie.
Je viens de lire votre question à nouveau et que vous ne mentionnez pas du tout localtstorage. Donc, si votre JWT n'est stocké que dans la mémoire, ce sera perdu lorsque vous rafraîchissez la page, comme le dit Mikeone dans son commentaire
fin d'édition
Si vous utilisez déjà LocalStorage, une raison valable serait si vous envisagez d'utiliser Universal angulaire pour effectuer un rendu côté serveur.
Si vous rendez le côté du serveur d'images, le stockage local n'existe pas et que vos appels d'API ne disposeront pas du jeton JWT inclus.
Cela signifie que la réponse du serveur vous redirigera éventuellement vous rediriger vers la page de connexion, même si vous êtes déjà connecté ou que vous pouvez voir brièvement la version publique de la page avant que les utilisateurs connectés que le contenu ne soit affiché au client côté client
Concernant le côté de la sécurité des choses, consultez Cette réponse
Parce que votre jeton sera parti si vous rafraîchissez la page ..?