跳到主要内容

使用 RBAC 保护 API 资源

除了通过确保存在有效的 JWT 来保护资源的保护你的 API之外，还可以应用基于角色的访问控制 (RBAC)。

在本文中，我们将重点介绍 RBAC 如何影响认证 (Authentication) 流程中的权限 (Scope) 委派和验证。

授权 (Authorization) 流程图​

如图所示，与基本 API 保护的主要区别在于权限 (Scopes) 的处理。Logto 不再直接授予所有请求的权限，而是根据用户的 RBAC 策略过滤它们。JWT 令牌将仅包含用户通过其角色授予的权限。在 API 端，在验证令牌的真实性后，还有一个额外的检查，以确保令牌包含请求资源所需的权限。

可选：处理用户权限更改​

用户权限可能会在会话期间发生变化——例如，他们可能被分配新的角色或修改现有角色权限。在这些情况下，检测这些变化并更新应用程序 UI 可能是必要的。

当用户权限发生变化时会发生什么？有两种情况。

系统中没有引入新权限​

即使在用户权限更改后，当前的访问令牌仍将保持有效，直到它们过期。然而，新权限将在后续访问令牌中反映出来，任何被撤销的权限将被省略。

以下是一些推荐的操作：

选项 1：使用短期访问令牌过期时间

短期访问令牌可确保更频繁地更新用户权限。在控制台的 API 资源 设置中配置令牌过期设置。缺点是这将增加你的令牌使用量。

选项 2：动态检查权限

定期调用 Logto Management API 端点（例如，SWR）或使用 WebSocket 等技术实现长连接，以动态获取用户权限。在检测到更改时，清除现有的访问令牌，新签发的令牌将自动反映权限范围的更改。- API：用户角色 - API：角色权限

当检测到权限更改时，首先从存储中清除访问令牌，然后调用 SDK 方法 getAccessToken() 获取新的访问令牌。新签发的访问令牌应反映权限更改。

系统中引入新权限并分配给用户​

当你的系统中引入新权限时会发生这种情况。在这种情况下，你需要在初始化 Logto 客户端时首先包含新引入的权限范围。例如：

new LogtoClient({
  appId: 'your-app-id',
  redirectUrl: 'your-redirect-url',
  resources: ['your-api-resource'],
  scopes: [
    // ... 你现有的权限范围,
    'new-scope',
  ],
});

其次，你的每个客户端应用程序需要重新同意或重新登录用户，以接收新的权限更改。然后，新权限范围将在新的访问令牌中反映出来。

重新同意的代码示例：

signIn({ redirectUrl: 'your-redirect-url', prompt: 'consent' });

Logto x Cloudflare Workers: 如何保护你的 Workers 免受公共访问？

为机器对机器通信保护你的 API 资源