Ajoutez des revendications personnalisées pour les jetons d'accès JWT avec Logto pour améliorer votre autorisation

Dans des articles précédents, nous avons mentionné que de plus en plus de systèmes utilisent des jetons d'accès au format JWT pour l'authentification et le contrôle d'accès des utilisateurs. L'une des raisons importantes de cela est que le JWT peut contenir certaines informations utiles, telles que les rôles et les permissions des utilisateurs. Ces informations peuvent nous aider à faire passer les informations d'identité des utilisateurs entre le serveur et le client, permettant ainsi une authentification et un contrôle d'accès des utilisateurs.

Habituellement, les informations contenues dans le JWT sont déterminées par le serveur d'authentification. Selon le protocole OAuth 2.0, le JWT contient généralement des champs tels que sub (sujet), aud (auditoire) et exp (date d'expiration), que l'on appelle communément des revendications. Ces revendications peuvent aider à vérifier la validité du jeton d'accès.

Cependant, il existe d'innombrables scénarios où le JWT est utilisé pour la vérification, et les revendications JWT courantes peuvent souvent ne pas répondre aux besoins des utilisateurs. Les gens pensent souvent que puisque le JWT peut contenir certaines informations, ne pourrait-on pas ajouter quelques informations supplémentaires pour faciliter l'autorisation ?

La réponse est OUI, nous pouvons ajouter des revendications personnalisées au JWT, telles que le champ d'application et le niveau d'abonnement de l'utilisateur actuel. De cette manière, nous pouvons faire passer les informations d'identité des utilisateurs entre le client et le serveur (ici se référant au serveur qui fournit divers services, également appelé fournisseur de services), pour réaliser l'authentification et le contrôle d'accès des utilisateurs.

Pour les revendications JWT standard, veuillez vous référer à RFC7519. Logto, en tant que solution d'identité qui prend en charge à la fois l'authentification et l'autorisation, a étendu les revendications de ressources et de champ d'application sur cette base pour prendre en charge le RBAC standard. Bien que la mise en œuvre du RBAC par Logto soit standard, elle n'est pas suffisamment simple et flexible pour s'adapter à tous les cas d'utilisation.

Sur cette base, Logto a lancé une nouvelle fonctionnalité de personnalisation des revendications JWT, qui permet aux utilisateurs de personnaliser des revendications JWT supplémentaires, afin que l'authentification et le contrôle d'accès des utilisateurs puissent être mis en œuvre de manière plus flexible.

Comment fonctionnent les revendications JWT personnalisées de Logto ?#

Vous pouvez accéder à la page de liste des JWT personnalisés en cliquant sur le bouton "JWT claims" dans la barre latérale.

Commençons par ajouter des revendications personnalisées pour les utilisateurs finaux.

Dans l'éditeur sur la gauche, vous pouvez personnaliser votre fonction getCustomJwtClaims. Cette méthode a trois paramètres d'entrée : token, data, et envVariables.

• token est le payload brut du jeton d'accès obtenu en fonction des identifiants de l'utilisateur actuel et de la configuration de votre système, ainsi que des informations relatives à l'accès de l'utilisateur dans Logto
• data est toute l'information sur l'utilisateur dans Logto, y compris tous les rôles de l'utilisateur, les identités de connexion sociale, les identités SSO, les appartenances à des organisations, etc.
• envVariables sont les variables d'environnement que vous avez configurées dans Logto pour le scénario d'utilisation des jetons d'accès de l'utilisateur actuel, telles que la ou les clés API des API externes requises, etc.

Les cartes sur la droite peuvent être agrandies pour montrer l'introduction des paramètres correspondants, et vous pouvez également définir ici les variables d'environnement pour le scénario actuel.

Après avoir lu les introductions de toutes les cartes sur la droite, vous pouvez passer en mode test, où vous pouvez éditer les données de test et utiliser les données de test éditées pour vérifier si le comportement du script que vous avez écrit dans l'éditeur de code sur la gauche répond à vos attentes.

Voici un diagramme de séquence montrant le processus d'exécution de la fonction getCustomJwtClaims lorsqu'un utilisateur final initie une demande d'authentification à Logto et obtient finalement le jeton d'accès au format JWT renvoyé par Logto.

Si la fonctionnalité JWT personnalisé n'est pas activée, l'étape 3 dans le schéma sera sautée et l'étape 4 sera exécutée juste après la fin de l'étape 2. À ce moment-là, Logto supposera que la valeur de retour de getCustomJwtClaims est un objet vide, puis continuera de suivre les étapes suivantes.

Améliorez votre autorisation avec des revendications JWT personnalisées : un exemple pratique#

Dans la section précédente, nous avons expliqué le principe de fonctionnement du JWT personnalisé de Logto. Dans cette partie, nous allons vous montrer comment utiliser les revendications JWT personnalisées de Logto pour améliorer la flexibilité de l'autorisation et la performance du fournisseur de services à travers un exemple concret.

Configuration du scénario#

L'équipe de John a développé une application d'assistant IA qui permet aux utilisateurs de converser avec des robots IA pour obtenir divers services.

Les services du robot IA sont divisés en services gratuits et services payants. Les services gratuits incluent des recommandations spéciales sur les tarifs aériens, tandis que les services payants incluent des prédictions boursières.

L'application d'assistant IA utilise Logto pour gérer tous les utilisateurs, qui sont divisés en trois types : utilisateurs gratuits, utilisateurs prépayés, et utilisateurs premium. Les utilisateurs gratuits ne peuvent utiliser que les services gratuits, les utilisateurs prépayés peuvent utiliser tous les services (facturés à l'utilisation), et les utilisateurs premium peuvent utiliser tous les services (mais avec des limites de taux pour prévenir les usages abusifs).

De plus, l'application d'assistant IA utilise Stripe pour gérer les paiements des utilisateurs et dispose de son propre service de journalisation pour enregistrer les journaux d'opérations des utilisateurs.

Configurations de Logto#

Nous créons d'abord des ressources API pour le service d'assistant IA et créons deux champs d'application, recommend:flight et predict:stock.

Ensuite, nous créons deux rôles, free-user et paid-user, et assignons les champs d'application correspondants :

• Assigner le champ d'application recommend:flight au rôle free-user.
• Assigner les deux champs d'application recommend:flight et predict:stock au rôle paid-user.

Enfin, nous créons trois utilisateurs, free-user, prepaid-user, et premium-user, et assignons les rôles correspondants :

• Assigner le rôle free-user à l'utilisateur free-user.
• Assigner le rôle paid-user aux utilisateurs prepaid-user et premium-user.

Comme indiqué dans l'image suivante, afin de mettre en œuvre les informations d'autorisation nécessaires pour le scénario décrit ci-dessus, nous espérons inclure les informations roles, balance et numOfCallsToday de l'utilisateur actuellement connecté dans le JWT. Lors de la vérification du jeton d'accès dans l'application d'assistant IA, ces informations peuvent être utilisées pour effectuer rapidement la vérification des permissions.

Après avoir configuré les envVariables, nous implémentons la fonction getCustomJwtClaims et cliquons sur le bouton "Run test" pour voir le résultat des revendications JWT supplémentaires en fonction des données de test actuelles.

Comme nous n'avons pas configuré les données de test pour data.user.roles, les roles affichés dans le résultat sont un tableau vide.

Vérifier si la fonctionnalité JWT personnalisé est activée#

Selon la configuration de Logto ci-dessus, nous avons obtenu les résultats correspondants dans le test. Ensuite, nous utiliserons l'application d'exemple fournie par Logto pour vérifier si notre JWT personnalisé est efficace. Trouvez le SDK avec lequel vous êtes familier chez Logto SDKs et déployez une application d'exemple selon la documentation et le dépôt GitHub correspondant.

Sur la base de la configuration décrite ci-dessus, en prenant le React SDK comme exemple, nous devons mettre à jour la configuration correspondante dans LogtoConfig :

Après avoir connecté l'utilisateur free_user à l'application d'exemple qui simule l'application d'assistant IA, nous pouvons voir les informations roles, balance, numOfCallsToday, isPaidUser et isPremiumUser que nous avons ajoutées en consultant la partie payload du jeton d'accès JWT.

Les valeurs de balance, numOfCallsToday, isPaidUser et isPremiumUser sont cohérentes avec le test précédent, et roles est égal à ["free-user"]. C'est parce que dans le processus réel de connexion de l'utilisateur final, nous obtiendrons toutes les données accessibles de l'utilisateur et les traiterons en conséquence.

Pour les utilisateurs premium, nous pouvons voir que roles est ["paid-user"] et que isPaidUser et isPremiumUser sont tous deux true.

Mettez à jour la logique d'autorisation du fournisseur de services#

Dans les étapes précédentes, nous avons ajouté des revendications personnalisées basées sur les besoins métier au jeton d'accès de l'utilisateur. Ensuite, nous pouvons utiliser ces revendications pour effectuer rapidement une vérification d'autorisation.

Ici, nous fournissons la logique de Logto pour vérifier les jetons d'accès JWT côté API. La mise en œuvre complète du code peut être trouvée dans le dépôt GitHub :

Vous pouvez vous référer à la logique de l'API Logto pour vérifier les jetons d'accès et la personnaliser en fonction de votre propre logique métier. Par exemple, pour le scénario de l'application d'assistant IA décrit ici, vous pouvez ajouter la logique de vérification des revendications personnalisées telles que roles, balance, numOfCallsToday, isPaidUser et isPremiumUser dans la fonction verifyBearerTokenFromRequest.

L'exemple ci-dessus concerne le scénario où il affecte la connexion de l'utilisateur final et l'obtention du jeton d'accès JWT. Si votre cas d'utilisation est machine-à-machine (M2M), vous pouvez également configurer les revendications JWT personnalisées pour les applications M2M séparément.

La configuration des JWT personnalisés pour les utilisateurs n'affectera pas le résultat des applications M2M obtenant des jetons d'accès, et vice versa.

En raison de la généralité des connexions M2M, Logto ne fournit actuellement pas la fonction permettant à la méthode getCustomJwtClaims des applications M2M d'accepter les données internes de Logto. Pour d'autres aspects, la méthode de configuration des JWT personnalisés pour les applications M2M est la même que pour les applications utilisateur. Cet article ne s'étendra pas sur ce sujet. Vous pouvez utiliser la fonctionnalité JWT personnalisé de Logto pour commencer.

Pourquoi utiliser des revendications JWT personnalisées ?#

Nous avons fourni le scénario de l'application d'assistant IA pour John et comment utiliser la fonctionnalité JWT personnalisé de Logto pour réaliser une vérification d'autorisation plus flexible. Dans ce processus, nous pouvons voir les avantages de la fonctionnalité JWT personnalisé :

1. Sans la fonctionnalité JWT personnalisé, les utilisateurs doivent demander une API externe (comme ce que vous faites dans getCustomJwtClaims) à chaque fois qu'ils vérifient les permissions. Pour le fournisseur de services qui fournit cette API, cela peut augmenter la charge supplémentaire. Avec la fonctionnalité JWT personnalisé, ces informations peuvent être mises directement dans le JWT, réduisant les appels fréquents à l'API externe.
2. Pour les fournisseurs de services, la fonctionnalité JWT personnalisé peut les aider à vérifier plus rapidement les permissions des utilisateurs, en particulier lorsque le client appelle fréquemment le fournisseur de services, améliorant ainsi les performances des services.
3. La fonctionnalité JWT personnalisé peut vous aider à mettre en œuvre rapidement des informations d'autorisation supplémentaires requises par le métier, et les informations peuvent être transmises entre le client et le fournisseur de services de manière sécurisée puisque le JWT est autonome et peut être crypté de manière à ce qu'il soit difficile à falsifier.

En même temps, puisque getCustomJwtClaims est exécuté chaque fois que l'utilisateur a besoin que Logto émette un jeton d'accès, il est nécessaire d'éviter d'exécuter une logique trop complexe et des requêtes vers des APIs externes avec des exigences de bande passante élevées. Sinon, cela pourrait prendre trop longtemps pour que les utilisateurs finaux attendent le résultat de getCustomJwtClaims pendant le processus de connexion. Si votre getCustomJwtClaims retourne un objet vide, nous vous recommandons vivement de supprimer temporairement cet élément de configuration jusqu'à ce que vous en ayez réellement besoin.

Conclusion#

Dans cet article, Logto a étendu le jeton d'accès JWT de base et a étendu la fonction des revendications supplémentaires JWT pour permettre aux utilisateurs d'insérer des informations supplémentaires sur l'utilisateur final dans le jeton d'accès JWT en fonction de leurs besoins métier, afin qu'après que l'utilisateur se soit connecté, les permissions de l'utilisateur puissent être rapidement vérifiées.

Nous fournissons le scénario de l'application d'assistant IA de John et montrons comment utiliser la fonctionnalité JWT personnalisé de Logto pour réaliser une vérification d'autorisation plus flexible. Nous avons également souligné certains points clés de l'utilisation des revendications JWT personnalisées. En combinaison avec des scénarios métier réels, les utilisateurs peuvent insérer diverses informations liées aux utilisateurs dans le jeton d'accès JWT en fonction de leurs besoins, de sorte que le fournisseur de services puisse rapidement vérifier les permissions de l'utilisateur.