常见用例
在本节中，我们将通过一些示例，帮助你理解 自定义访问令牌 (Access token) 声明 (Claims) 在某些场景下的应用，为你提供一些参考。这样，当你在访问管理中遇到困难时，可以评估自定义访问令牌 (Access token) 声明 (Claims) 是否能为你带来便利。
实现基于属性的访问控制 (ABAC)
基于属性的访问控制 (ABAC) 是一种使用属性（如用户角色、资源属性和环境条件）来做出访问控制决策的访问控制模型。这是一种灵活且动态的受保护资源访问管理方式。
假设你正在开发一个应用，该应用的发布分为两个阶段：公开测试和正式上线。即使在应用正式上线后，你仍希望参与过公开测试的老用户可以继续使用付费功能。
在应用正式上线后，你可以使用 Logto 的 基于角色的访问控制 (RBAC) 功能来实现对付费功能的访问控制。为了方便判断某个用户是否在公开测试阶段就已经在使用应用，你可以通过 getCustomJwtClaims() 方法在令牌 (Token) 载荷中添加一个 createdAt 声明 (Claim)。
然后，在你的受保护 API 中进行访问控制时，你需要允许满足以下任一条件的访问令牌 (Access token)：
- 在 RBAC 上下文中，拥有访问付费资源的权限 (Scope)。
createdAt早于公开测试阶段的结束时间。
如果没有自定义令牌 (Token) 声明 (Claims) 功能，在进行 授权 (Authorization) 权限校验时，就需要调用 Logto Management API，检查当前访问令牌 (Access token) 所对应的用户是否拥有某个 API 资源所需角色的权限。
在类似场景下，假设你的应用希望在用户生日临近时，在登录页面显示生日祝福。你可以通过自定义令牌 (Token) 声明 (Claims) 在 令牌 (Token) 载荷 中添加生日字段，用于判断是否显示特定消息。
手动阻止令牌 (Token) 签发
假设 Joe 正在运营一款网络游戏，并使用 Logto 作为 身份与访问管理 (IAM) 系统。
假设这款游戏需要充值购买游戏时间。Joe 在自己的游戏服务中记录每个用户的余额，并随着游戏时间的累计不断扣减余额。当账户余额耗尽时，Joe 希望强制玩家退出登录，以鼓励他们充值。
此时，Joe 也可以利用 Logto 提供的自定义令牌 (Token) 声明 (Claims) 功能来实现：
- 在脚本中，可以通过外部 API 调用 获取外部数据 的方式，从 Joe 的游戏服务器获取当前玩家的余额。
- 如果余额小于或等于 0，可以通过
api.denyAccess()方法阻止令牌 (Token) 签发。
此时，由于无法获取新的有效访问令牌 (Access token)，玩家将被强制退出游戏。