La définition de rôles dans JWT est-elle une meilleure pratique?
J'envisage d'utiliser JWT. Dans exemple jwt.io je vois les informations suivantes dans les données de charge utile:
"admin": true
L'administrateur peut être considéré comme un rôle, d'où ma question. La définition du rôle dans la charge utile symbolique est-elle une pratique habituelle/bonne? Étant donné que les rôles peuvent être modifiés dynamiquement, je suis assez interrogatif.
Rien ne vous empêche de créer des revendications pour stocker des informations supplémentaires dans votre jeton si elles peuvent être utiles pour votre client.
Cependant, je ne compterais sur JWT que pour authentification (qui est l'appelant). Si vous devez effectuer autorisation (ce que l'appelant peut faire), recherchez les rôles/autorisations de l'appelant à partir de votre stockage persistant pour obtenir la valeur la plus à jour.
Le site officiel de JWT mentionne explicitement "autorisation" (contrairement à "authentification") comme cas d'utilisation pour les JWT:
Quand devez-vous utiliser des jetons Web JSON? Autorisation: C'est le scénario le plus courant pour utiliser JWT. Une fois l'utilisateur connecté, chaque demande ultérieure inclura le JWT, permettant à l'utilisateur d'accéder aux routes, services et ressources autorisés avec ce jeton. La connexion unique est une fonctionnalité qui utilise largement JWT de nos jours, en raison de sa faible surcharge et de sa capacité à être facilement utilisée dans différents domaines.
Cela étant dit, du point de vue de la sécurité, vous devriez réfléchir à deux fois si vous voulez vraiment inclure des rôles ou des autorisations dans le jeton.
(Le texte ci-dessous peut être compris comme un suivi plus "approfondi" de la réponse acceptée plutôt brève)
Une fois que vous avez créé et signé le jeton, vous accordez l'autorisation jusqu'à l'expiration du jeton. Mais que se passe-t-il si vous accordez des autorisations d'administrateur par accident? Jusqu'à l'expiration du jeton, quelqu'un opère désormais sur votre site avec des autorisations attribuées par erreur.
Certaines personnes pourraient soutenir que le jeton est de courte durée, mais ce n'est pas un argument solide étant donné la quantité de mal qu'une personne peut faire en peu de temps. Certaines autres personnes préconisent de maintenir une table de base de données de liste noire distincte pour les jetons, ce qui résout le problème de l'invalidation des jetons, mais ajoute une sorte de suivi de l'état de la session au backend, car vous devez maintenant garder une trace de toutes les sessions en cours qui existent. - vous devrez donc effectuer un appel db à la liste noire à chaque fois qu'une demande arrive pour vous assurer qu'elle ne l'est pas encore. On peut faire valoir que cela va à l'encontre du but de "ne pas mettre les rôles dans le JWT pour éviter un appel de base supplémentaire": si vous effectuez un appel de base vers une liste noire, vous pouvez également effectuer un appel de base pour récupérer le rôles et éviter d'avoir une liste noire.
Ainsi, au lieu d'ajouter des revendications d'autorisation au jeton, vous pouvez conserver des informations sur les rôles et les autorisations des utilisateurs dans la base de données de votre serveur d'authentification sur laquelle vous avez un contrôle total à tout moment (par exemple, pour révoquer une certaine autorisation pour un utilisateur). Si une demande arrive, vous récupérez les rôles actuels à partir du serveur d'authentification (ou partout où vous stockez vos autorisations).
Soit dit en passant, si vous jetez un œil à la liste des revendications publiques enregistrées par l'IANA , vous verrez que ces revendications évoluent autour de l'authentification et ne traitent pas de ce que l'utilisateur est autorisé à faire (autorisation ).
Donc, en résumé, vous pouvez ...
ajoutez des rôles à votre JWT si (a) la commodité est importante pour vous et (b) vous voulez éviter des appels de base de données supplémentaires pour récupérer les autorisations et (c) ne se soucient pas des petites fenêtres temporelles dans lesquelles une personne a des droits attribués qu'elle ne devrait pas avoir et (d) vous ne vous souciez pas de la (légère) augmentation de la charge utile du JWT résultant de l'ajout des autorisations.
ajoutez des rôles à votre JWT et utilisez une liste noire si (a) vous voulez empêcher toute fenêtre de temps dans laquelle une personne a des droits attribués, elle ne devrait pas avoir et (b) accepter que cela se fasse au détriment de la demande d'une liste noire pour chaque demande entrante et (c) vous ne vous souciez pas de la (légère) augmentation de la charge utile du JWT résultant de l'ajout des autorisations.
ne pas ajouter de rôles à votre JWT et les récupérer à la demande si (a) vous voulez empêcher toute fenêtre de temps dans laquelle une personne a des droits attribués, elle ne devrait pas ' t ou ou (b) éviter les frais généraux d'une liste noire ou (c) éviter d'augmenter la taille de votre charge utile JWT pour augmenter légèrement et (d) si vous acceptez que cela se fasse au prix de l'interrogation parfois/toujours des rôles sur les demandes entrantes .
Comme mentionné ici , ASP.NET Core détectera automatiquement tout roles mentionné dans le JWT:
{
"iss": "http://www.jerriepelser.com",
"aud": "blog-readers",
"sub": "123456",
"exp": 1499863217,
"roles": ["Admin", "SuperUser"]
}
et les "mapper" à Rôles ASP.NET qui sont couramment utilisés pour sécuriser certaines parties de votre application.
[Authorize(Roles = "Admin")]
public class SettingsController : Controller
Le serveur qui distribue (et signe) le JWT est communément appelé autorisation serveur et pas seulement un serveur d'authentification , il est donc logique d'inclure les informations de rôle (ou la portée) dans le JWT, même si elles ne le sont pas revendications enregistrées .