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 souhaite utiliser le jeton JWT pour eux sont:

Meilleure protection contre la modification côté client des revendications (c.-à-d. 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.

— Astravagrant
source

lire ceci maintenant .... et aimerais une mise à jour si vous le pouvez. Je serais intéressé par ce que vous avez fait, car je suis confronté à la même chose. Je pense et je ne sais pas comment certaines pièces sont censées fonctionner. l'utilisateur obtient un jeton d'autorisation, mais alors comment les réclamations doivent-elles être effectuées ... pourriez-vous expliquer vos conclusions ... car cela m'aiderait probablement.

— Seabizkit

Réponses:

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.

— wchoward
source

À la vôtre, DL. Mettez-vous en cache les rôles, etc. sur le serveur API, ou appuyez-vous simplement deux fois sur la base de données chaque fois que vous recevez une demande? (c'est-à-dire une fois pour les rôles et une fois pour les données réelles demandées). Si vous le cachez, je serais intéressé de savoir quelle méthode vous utilisez. En outre, voulez-vous dire que vous cryptez davantage l'ID utilisateur `` à l'intérieur '' du jeton déjà crypté? Merci.

— Astravagrant le

Je ne suis pas encore allé aussi loin dans mon implémentation :), mais oui, je pensais utiliser un serveur de mise en cache afin que je ne frappe pas la base de données aussi souvent et si un rôle change, le cache pourrait être supprimé pour permettre la nouvelle rôle demandé pour charger le cache enregistré. Dans mon cas, j'utiliserais probablement Amazon AWS elsticache qui est basé sur le memcached ouvert mais plus facile à configurer et à utiliser.

— wchoward

Je pense également que c'est une meilleure idée d'obtenir toutes les informations nécessaires sur le serveur de ressources et de ne pas les stocker dans un jeton.

— Mateusz Migała

Donc, pour chaque demande, vous obtenez les rôles d'utilisateurs ... revendications ..., pourriez-vous me signaler un article ou quelque chose qui montre que cela est faisable. Je suis actuellement en train d'utiliser la session, mais je cherche une meilleure façon de faire les choses, mais la recherche à chaque demande ne me semble pas correcte?

— Seabizkit

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.

— Chad Clark
source

N'oubliez pas que même lorsque vous vérifiez l'autorisation dans l'interface utilisateur, vous devez toujours vérifier l'autorisation côté serveur lorsqu'une demande arrive.

— Chad Clark