一般的なユースケース
このセクションでは、カスタムトークンクレーム が役立つシナリオの例をいくつか紹介し、参考にしていただきます。これにより、アクセス管理で困難に直面したときに、カスタムトークンクレームが便利さをもたらすかどうかを評価できます。
属性ベースのアクセス制御 (ABAC) を可能にする
属性ベースのアクセス制御 (ABAC) は、属性（ユーザーロール、リソースの特性、環境条件など）を使用してアクセス制御の決定を行うアクセス制御モデルです。これは、保護されたリソースへのアクセスを管理するための柔軟で動的な方法です。
アプリを構築していると仮定し、そのアプリのリリースがパブリックベータと公式リリースの 2 つのフェーズに分かれているとします。アプリが公式にリリースされた後でも、パブリックベータに参加した古いユーザーが有料機能を引き続き使用できるようにしたいと考えています。
アプリが公式にリリースされた後、Logto の ロールベースのアクセス制御 (RBAC) 機能を使用して、有料機能の使用に対するアクセス制御を実装します。ユーザーがパブリックベータフェーズ中にすでにアプリを使用していたかどうかを簡単に確認するために、getCustomJwtClaims() メソッドを使用してトークンペイロードに createdAt クレームを追加できます。
その後、保護された API でアクセス制御を行う際に、次のいずれかの条件を満たすアクセス トークンを許可する必要があります：
- RBAC コンテキストを持ち、有料リソースにアクセスするためのスコープを持っている。
createdAtがパブリックベータフェーズの終了時間よりも前である。
カスタムトークンクレーム機能がない場合、保護された API リソース の権限を検証する際に、現在のアクセス トークンを持つユーザーが特定の API リソースに必要なロールに対応する権限を持っているかどうかを確認するために Logto Management API を呼び出す必要があります。
同様のシナリオで、ユーザーの誕生日が近づいている場合にログインページに誕生日メッセージを表示するアプリを想定します。カスタムトークンクレームを使用して トークンペイロード に誕生日フィールドを追加し、特定のメッセージを表示するかどうかを判断することができます。
トークン発行を手動でブロックする
ジョーがオンラインゲームを運営しており、Logto を アイデンティティとアクセス管理 (IAM) システムとして使用していると仮定します。
このゲームでは、ゲーム時間を購入するためにチャージが必要であると仮定します。ジョーは各ユーザーの残高をゲームサービスに記録し、ゲーム時間が経過するにつれて残高を継続的に差し引きます。ジョーは、アカウント残高がなくなったときにプレイヤーを強制的にログアウトさせ、再チャージを促したいと考えています。
この時点で、ジョーは Logto が提供するカスタムトークンクレーム機能を使用してこれを実現できます：
- スクリプト内で、外部 API 呼び出しを使用してジョーのゲームサーバーから現在のプレイヤーの残高を取得することができます 外部データを取得する。
- 残高が 0 以下の場合、
api.denyAccess()メソッドを使用してトークン発行をブロックできます。
この時点で、新しい有効なアクセス トークンを取得できないため、プレイヤーはゲームから強制的にログアウトされます。