Aller au contenu principal

Cas d'utilisation courants

Dans cette section, nous fournirons quelques exemples pour vous aider à comprendre certains scénarios où les revendications de jetons personnalisés peuvent être utiles, vous offrant ainsi quelques références. De cette façon, lorsque vous rencontrez des difficultés dans la gestion des accès, vous pouvez évaluer si les revendications de jetons personnalisés 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. C'est un moyen flexible et dynamique de gérer l'accès aux ressources protégées.

Supposons que vous construisiez une application, et que la sortie de l'application soit divisée 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 continuent à 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 pour l'utilisation des fonctionnalités payantes. Pour vérifier facilement si un utilisateur utilisait déjà l'application pendant la phase 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 répondent à l'une des conditions suivantes :

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

S'il n'y a pas de fonctionnalité de revendications de jetons personnalisés, lors de la vérification des permissions pour les ressources API protégées, il est nécessaire d'appeler le Logto Management API pour vérifier si l'utilisateur avec le jeton d’accès actuel a les 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 des revendications de jetons personnalisés pour ajouter un champ d'anniversaire à la charge utile du jeton, qui peut être utilisé pour 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).

Supposons 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 déduit continuellement du solde à mesure que le temps de jeu s'accumule. Joe veut forcer les joueurs à se déconnecter lorsque leur solde est épuisé pour les encourager à recharger.

À ce stade, Joe peut également utiliser la fonctionnalité de revendications de jetons personnalisés fournie par Logto pour y parvenir :

  1. Dans le script, un appel API externe fetch external data peut être utilisé pour récupérer 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 de jetons.

À ce moment-là, comme un nouveau jeton d’accès valide ne peut pas être obtenu, le joueur sera forcé de se déconnecter du jeu.