Dans ma demande, j'ai des microservices distincts pour l'authentification de l'utilisateur et les informations de profil utilisateur. Le service d'authentification de l'utilisateur utilise Security Spring Oauth2 / JWT. Une fois qu'un utilisateur se connecte correctement, un jeton JWT est émis avec l'identifiant unique d'utilisateur.
Ma requête est la manière dont les autres services devraient récupérer des informations de profil utilisateur. Dois-je mettre ces informations (telles que prénom, nom de famille, etc.) dans le jeton JWT ou dois-je créer une API sur le service de profil utilisateur qui récupère les informations de profil utilisateur une fois que le jeton est récupéré?
Tous les meilleurs conseils de pratique seraient appréciés.
3 Réponses :
Jusqu'à présent, la plupart des approches que j'ai vues étaient de stocker uniquement la connexion de l'utilisateur dans JWT Token et d'avoir un autre service qui vous donne d'autres informations nécessaires par Connexion, ce qui semble être la meilleure approche de moi (en cas de connexion de toute sécurité de la sécurité. est la seule chose qui puisse être volée, et non le premier ou le nom de famille de l'utilisateur).
Merci Kamil, je pense que la route API est la voie à suivre. C'est une autre demande une fois que vous récupérez le jeton, mais cela donne l'avantage de fournir le profil complet de l'utilisateur sans avoir à sortir des données sensibles que vous ne voudrez peut-être pas mettre dans le jeton JWT.
Je pense qu'il est important de souligner que OAuth2 est destiné à être une autorisation OpenID Connect résout ce problème en séparant l'identité (ID_Tokoke) et l'autorisation (jeton d'accès) en deux jetons différents pour l'application à consommer. Plutôt que de mettre en œuvre le vôtre, puis-je suggérer que vous envisagez OpenID Connect?
J'ai eu des discussions similaires avec mon équipe tout en travaillant sur le microservice d'authentification. Bien qu'il soit important de comprendre que JWT est un codage et non un cryptage, il est donc toujours conseillé de ne pas conserver les données sensibles dans JWT. Bien que les articles que nous décidons de garder à JWT devraient également dépendre de la déclaration de problème que nous résolvons. Il peut y avoir des cas d'utilisation où l'enregistrement du nom d'utilisateur ou de l'identifiant de messagerie n'est pas une information sensible et vous voudrez peut-être garder cela dans JWT simplement pour éviter un appel supplémentaire d'API.