Cas d’utilisation courants

Dans cette section, nous vous proposons quelques exemples pour vous aider à comprendre certains scénarios où les revendications personnalisées de jeton peuvent être utiles, en vous offrant quelques références. Ainsi, lorsque vous rencontrez des difficultés dans la gestion des accès, vous pourrez évaluer si les revendications personnalisées de jeton peuvent vous apporter de la commodité.

Rendre possible le contrôle d’accès basé sur les attributs (ABAC)

Le contrôle d’accès basé sur les attributs (ABAC) est un modèle de contrôle d’accès qui utilise des attributs (tels que les rôles des utilisateurs, les propriétés des ressources et les conditions environnementales) pour prendre des décisions de contrôle d’accès. Il s’agit d’une méthode flexible et dynamique pour gérer l’accès aux ressources protégées.

Supposons que vous développez une application, et que la sortie de l’application se déroule en deux phases : bêta publique et lancement officiel. Même après le lancement officiel de l’application, vous souhaitez que les anciens utilisateurs ayant participé à la bêta publique puissent continuer à utiliser les fonctionnalités payantes.

Après le lancement officiel de l’application, vous utilisez la fonctionnalité de contrôle d’accès basé sur les rôles (RBAC) de Logto pour mettre en œuvre le contrôle d’accès à l’utilisation des fonctionnalités payantes. Pour vérifier facilement si un utilisateur utilisait déjà l’application pendant la phase de bêta publique, vous pouvez utiliser la méthode getCustomJwtClaims() pour ajouter une revendication createdAt dans la charge utile du jeton.

Ensuite, lors du contrôle d’accès dans vos API protégées, vous devez autoriser les jetons d’accès qui remplissent l’une des conditions suivantes :

1. Dans le contexte RBAC, disposer de la portée pour accéder aux ressources payantes.
2. Le champ createdAt est antérieur à la date de fin de la phase de bêta publique.

S’il n’existait pas de fonctionnalité de revendications personnalisées de jeton, lors de la vérification des permissions pour l’autorisation, il serait nécessaire d’appeler la Management API Logto pour vérifier si l’utilisateur possédant le jeton d’accès actuel dispose des permissions correspondant au rôle requis par une certaine ressource API.

Dans un scénario similaire, supposons que votre application affiche des vœux d’anniversaire sur la page de connexion si l’anniversaire de l’utilisateur approche. Vous pouvez utiliser les revendications personnalisées de jeton pour ajouter un champ anniversaire à la charge utile du jeton, qui pourra servir à déterminer s’il faut afficher un message spécifique.

Bloquer manuellement l’émission de jetons

Supposons que Joe gère un jeu en ligne et utilise Logto comme système de gestion des identités et des accès (IAM).

Imaginons que ce jeu nécessite des recharges pour acheter du temps de jeu. Joe enregistre le solde de chaque utilisateur dans son service de jeu et le déduit continuellement au fur et à mesure que le temps de jeu s’accumule. Joe souhaite forcer les joueurs à se déconnecter lorsque leur solde est épuisé afin de les inciter à recharger.

À ce stade, Joe peut également utiliser la fonctionnalité de revendications personnalisées de jeton fournie par Logto pour atteindre cet objectif :

1. Dans le script, un appel API externe récupérer des données externes peut être utilisé pour obtenir le solde actuel du joueur depuis le serveur de jeu de Joe.
2. Si le solde est inférieur ou égal à 0, la méthode api.denyAccess() peut être utilisée pour bloquer l’émission du jeton.

À ce moment-là, puisqu’il n’est plus possible d’obtenir un nouveau jeton d’accès valide, le joueur sera automatiquement déconnecté du jeu.