跳到主要内容

常见用例

在本节中，我们将通过一些示例，帮助你理解 自定义令牌声明 (Claims) 在某些场景下的应用，为你提供一些参考。这样，当你在访问管理中遇到困难时，可以评估自定义令牌声明 (Claims) 是否能为你带来便利。

实现基于属性的访问控制 (ABAC)​

基于属性的访问控制 (ABAC) 是一种使用属性（如用户角色、资源属性和环境条件）来做出访问控制决策的访问控制模型。这是一种灵活且动态的方式，用于管理对受保护资源的访问。

假设你正在构建一个应用，该应用的发布分为两个阶段：公开测试和正式上线。即使在应用正式上线后，你也希望曾经参与公开测试的老用户可以继续使用付费功能。

在应用正式上线后，你可以使用 Logto 的 基于角色的访问控制 (RBAC) 功能来实现对付费功能的访问控制。为了方便判断某个用户是否在公开测试阶段就已经在使用应用，你可以通过 getCustomJwtClaims() 方法，在令牌 (token) 负载中添加一个 createdAt 声明 (Claim)。

然后，在你的受保护 API 中进行访问控制时，你需要允许满足以下任一条件的访问令牌 (Access token)：

  1. 在 RBAC 上下文中，拥有访问付费资源的权限 (Scope)。
  2. createdAt 早于公开测试阶段的结束时间。

如果没有自定义令牌声明 (Claims) 功能，在进行 授权 (Authorization) 权限校验时，就需要调用 Logto Management API，检查当前访问令牌 (Access token) 所属用户是否拥有某个 API 资源所需角色对应的权限。

在类似场景下，假设你的应用希望在用户生日临近时，在登录页面展示生日祝福。你可以通过自定义令牌声明 (Claims) 在 令牌负载 (Token payload) 中添加生日字段，用于判断是否展示特定消息。

手动阻止令牌 (Token) 签发​

假设 Joe 正在运营一款网络游戏，并使用 Logto 作为 身份与访问管理 (IAM) 系统。

假设这款游戏需要充值购买游戏时长。Joe 在自己的游戏服务中记录每个用户的余额，并随着游戏时长的累计不断扣减余额。Joe 希望当玩家余额耗尽时强制其退出登录，以促使充值。

此时，Joe 也可以利用 Logto 提供的自定义令牌声明 (Claims) 功能来实现：

  1. 在脚本中，可以通过外部 API 调用 获取外部数据 的方式，从 Joe 的游戏服务器获取当前玩家的余额。
  2. 如果余额小于或等于 0，可以通过 api.denyAccess() 方法阻止令牌 (Token) 签发。

此时，由于无法获取新的有效访问令牌 (Access token)，玩家将被强制退出游戏。