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