Dois-je stocker mes réclamations utilisateur dans le jeton JWT?
J'utilise des jetons JWT dans les en-têtes HTTP pour authentifier les demandes auprès d'un serveur de ressources. Le serveur de ressources et le serveur d'authentification sont deux rôles de travail distincts sur Azure.
Je ne peux pas décider si je dois stocker les revendications dans le jeton ou les joindre à la demande/réponse d'une autre manière. La liste des revendications affecte le rendu des éléments d'interface utilisateur côté client ainsi que l'accès aux données sur le serveur. Pour cette raison, je veux m'assurer que les réclamations reçues par le serveur sont authentiques et validées avant le traitement de la demande.
Des exemples de revendications sont: CanEditProductList, CanEditShopDescription, CanReadUserDetails.
Les raisons pour lesquelles je veux utiliser le jeton JWT pour eux sont:
- Meilleure protection contre la modification côté client des revendications (c'est-à-dire piratage de la liste des revendications).
- Pas besoin de rechercher les réclamations à chaque demande.
Les raisons pour lesquelles je ne veux pas utiliser le jeton JWT:
- Le serveur d'authentification doit alors connaître la liste des revendications centrées sur l'application.
- Le jeton devient un point d'entrée unique.
- J'ai lu quelques choses en disant que les jetons JWT ne sont pas destinés aux données au niveau de l'application.
Il me semble que les deux ont des inconvénients, mais je penche pour l'inclusion de ces revendications dans le jeton et je veux juste gérer cela par des personnes qui ont déjà traité cela.
REMARQUE: je vais utiliser HTTPS pour toutes les demandes d'API, il me semble donc que le jeton sera suffisamment "sûr". J'utilise AngularJS, C #, Web API 2 et MVC5.
Je stocke uniquement les revendications d'identifiant (ID utilisateur, etc.) (cryptées) dans mon jwt.
Ensuite, lorsque j'obtiens le jeton sur le serveur (API), je peux faire une recherche côté serveur (db ou appel api du réseau local) et récupérer toutes les associations avec l'ID utilisateur (applications, rôles, etc.)
Cependant, si vous souhaitez ajouter plus de détails dans le jwt, soyez prudent avec la taille, car il sera probablement envoyé à chaque demande, mais assurez-vous de crypter les données de réclamation sensibles.
Cela ressemble à l'authentification (qui est l'utilisateur) et l'autorisation (ce que l'utilisateur est autorisé à faire) ne sont pas aussi clairement divisées que vous le souhaitez.
Si vous ne voulez pas que le serveur d'authentification sache à quoi l'utilisateur a droit, limitez les revendications de ce JWT à l'ID utilisateur, comme l'a suggéré wchoward. Vous pouvez demander à un autre serveur appelé serveur d'autorisation de rechercher ce à quoi l'utilisateur a droit.
L'étape d'autorisation peut être effectuée par le serveur de ressources lors de la première présentation d'un jeton d'authentification par le client. Le serveur de ressources enverrait alors un jeton au client contenant les revendications d'autorisation.
Remarque: Les deux JWT doivent être signés par des clés différentes.
Avantages:
- L'authentification et l'autorisation sont gérées séparément.
- Le serveur de ressources n'a pas à rechercher d'autorisation sur chaque demande.
- L'interface utilisateur a accès pour voir l'autorisation mais pas la modifier.
Con:
- Le client doit gérer deux jetons au lieu d'un.
- L'ajout d'un serveur d'autorisation ajoute une autre partie mobile à gérer.