Les autorisations d'accès et les rôles doivent-ils être inclus dans la charge utile de JWT?

Les informations sur les autorisations et les rôles du client doivent-elles être incluses dans JWT?

Avoir de telles informations dans le jeton JWT sera très utile car à chaque fois qu'un jeton valide arrive, il serait plus facile d'extraire les informations sur l'autorisation de l'utilisateur et il ne sera pas nécessaire d'appeler la base de données pour la même chose. Mais le fait d'inclure de telles informations et de ne pas les vérifier dans la base de données sera-t-il un problème de sécurité?

Ou,

Des informations comme celles mentionnées ci-dessus ne devraient jamais faire partie de JWT, et seule la base de données devrait être utilisée pour vérifier les rôles d'accès et les autorisations d'un utilisateur.

security authentication jwt

— Anshul Sahni
source

Réponses:

Le but d'inclure des revendications dans le jeton est de ne pas avoir cette communication entre la ressource et le fournisseur d'authentification.

La ressource peut simplement vérifier que le jeton a une signature valide et faire confiance au contenu.

En supposant que la clé privée est privée du serveur d'authentification, vous êtes bon. Certains fournisseurs changent de clé pour atténuer le risque.

Si vous y pensez, si la ressource a rappelé le serveur d'authentification pour obtenir les revendications. Ensuite, il s'assure essentiellement qu'il parle au bon serveur par des méthodes de confiance similaires.

— Ewan
source

Eh bien merci pour une belle réponse, puis-je en savoir plus sur ce que vous vouliez dire dans votre déclaration "Certains fournisseurs changent de clé pour atténuer le risque". ?

— Anshul Sahni

Ainsi, plutôt que d'avoir une clé de signature fixe, le fournisseur d'authentification la changera de temps en temps et fournira un point de terminaison pour que les serveurs de ressources puissent en télécharger la moitié publique. Les ressources doivent appeler le serveur d'authentification de temps en temps, mais pas une fois par demande

— Ewan

Tous les jetons sont donc invalides chaque fois que la signature de la clé est modifiée par le service

— Anshul Sahni

généralement, ils auront plus d'une clé possible, de sorte qu'en vol, les jetons ne seront pas invalidés. le jeton contiendra un «identifiant de clé» pour indiquer à la ressource laquelle utiliser

— Ewan

La seule chose qui me manque ici est de savoir comment procéder lorsque les données du JWT sont invalidées. Disons que les rôles ont changé côté serveur mais que le client détient toujours le jeton avec l'ensemble des rôles. Vous devez être en mesure de révoquer des jetons côté serveur afin que ces jetons contenant des informations obsolètes ne soient plus valides et utilisables pour d'autres demandes. Ceci est conforme à ce que Ewans suggère en quelque sorte (permettant au serveur de révoquer le jeton) pour une raison ou une autre.

— Laiv

D'après mon expérience, si tous vos systèmes utilisent une base de données de rôles et d'autorisations centrale, vous pouvez ajouter tout cela dans JWT.

Cependant, cette approche peut ne pas fonctionner correctement dans les scénarios d'authentification unique lorsque le serveur d'authentification lui-même n'a aucune idée du système cible qui recevra et approuvera le jeton.

Les rôles et autorisations de l'utilisateur sont entièrement sur le récepteur du jeton JWT. C'est particulièrement vrai lorsque vous intégrez l'authentification SSO avec JWT dans certains systèmes hérités qui ont déjà leur sous-système d'autorisation en place et qu'ils n'ont donc besoin que d'une seule revendication pour être présente dans JWT - la revendication d'identité de l'utilisateur.

— JustAMartin
source

Je suis d'accord là-dessus. Les autorisations des utilisateurs ne devraient pas faire partie de jwt spécialement dans SSO car l'idp ne sait pas à quels autres services cet utilisateur jwt va parler.

— Manish Rawat

Je conviens également que les demandes d'autorisation dans les JWT ne sont pas une bonne idée au-delà d'une simple API monolithique. J'ai écrit un blog à ce sujet: sdoxsee.github.io/blog/2020/01/06/…

— sdoxsee