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