Aller au contenu principal

Cas d'utilisation courants

Dans cette section, nous vous fournirons quelques exemples pour vous aider à comprendre certains scénarios où les revendications de jeton personnalisées peuvent être utiles, en vous offrant 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 jeton personnalisées peuvent vous apporter de la commodité.

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

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 qui ont 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 à 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 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 de bêta publique.

S'il n'y a pas de fonctionnalité de revendications de jeton personnalisées, lors de la vérification des permissions pour les ressources API protégées, il est nécessaire d'appeler le Management API de Logto 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 les revendications de jeton personnalisées 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 de compte est épuisé pour les encourager à recharger.

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

  1. Dans le script, un appel API externe récupérer des données externes 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à, puisqu'un nouveau jeton d’accès valide ne peut pas être obtenu, le joueur sera forcé de se déconnecter du jeu.