简体中文
  • release
  • API SDK
  • Vault
  • account API

Logto 产品更新

🎉 推出七月版本:Logto API SDK、用于联合令牌存储的密钥保险库,通过账户 API 管理 TOTP 和备份码,以及更多功能!

Simeng
Simeng
Developer

不要在用户认证上浪费数周时间
使用 Logto 更快地发布安全应用。几分钟内集成用户认证,专注于您的核心产品。
立即开始
Product screenshot

Logto API SDK

一个用于通过客户端凭据认证与 Logto 管理 API 交互的 TypeScript SDK。

工作原理

  1. 在 Logto 控制台创建一个机器对机器的应用。
  2. 授予该应用访问管理 API 的权限。
  3. 通过 npm 安装 SDK:npm install @logto/api
  4. 使用 createManagementApi(),用你的应用凭据创建一个类型化的管理 API 客户端。

亮点

  • 自动处理 OAuth 令牌身份验证和续期。
  • 支持 Logto Cloud 和自托管实例。
  • 简化与 Logto 管理 API 的集成,让你专注于开发功能而不是处理底层 API 请求。

密钥保险库

密钥保险库是 Logto 中用于管理敏感用户数据(包括访问令牌、API 密钥、通行码以及其它机密信息)的安全存储解决方案。 这些密钥通常用于代表用户访问第三方服务,因此安全存储至关重要。

支持联合令牌存储

现在社交和企业 SSO 连接器都支持令牌存储。启用后,Logto 会在成功认证后存储身份提供方签发的令牌集。应用随后可以随时检索访问令牌 —— 无需让用户重新认证 —— 来调用第三方 API。

支持的连接器:

  • 社交连接器:GitHubGoogleFacebook标准 OAuth 2.0标准 OIDC
  • 企业 SSO 连接器:所有基于 OIDC 的 SSO 连接器

工作方式:

  1. 在 Logto 控制台或通过 Logto 管理 API 启用社交和企业 SSO 连接器令牌存储功能。
  2. 启用后,Logto 在用户成功认证后会自动存储服务方签发的令牌集。
  3. 后续需要时,通过账户 API 检索已存储的令牌。

更多详情,请参阅 密钥保险库文档

通过账户 API 添加 TOTP 和备份码

用户现在可以通过账户 API 添加 TOTP 和备份码。

  • POST /api/my-account/mfa-verifications/totp-secret/generate:生成 TOTP 密钥。
  • POST /api/my-account/mfa-verifications/backup-codes/generate:生成备份码。
  • POST /api/my-account/mfa-verifications:使用已生成的密钥或备份码添加 TOTP 或备份码。
  • GET /api/my-account/mfa-verifications/backup-codes:获取备份码。

其它改进

  • 社交连接器:在生成社交连接器授权 URL 时,增加自定义 scope 参数的支持。 这允许你在调用 Logto 的 社交验证端点 时向社交提供方请求额外权限。如果设置了 scope,则授权请求会使用它,否则会使用连接器设置中的默认 scope。
  • 控制台:为更好地支持新的密钥保险库功能,我们重构了用户详情页的布局。 用户的社交和企业 SSO 身份现在组织在新的“连接”版块中。 该版块列出用户所有已绑定的连接,显示第三方身份信息及令牌存储状态(如适用)。每个连接还可进入详细的用户身份页,查看更多关于已绑定身份及其关联令牌的信息。

Bug 修复

organization_user_relations 表的租户感知外键约束

问题

开发者可能会错误地将其它租户的 user_id 分配给某个组织,导致组织用户 API 端点出现 500 错误。 原始的 organization_user_relations 表仅对 users (id) 设置了外键约束,允许分配任意存在的用户 ID,无视租户隔离。

根本原因

Logto 在所有表上应用了行级安全(RLS),实现租户数据访问隔离。 当将用户表与 organization_user_relations 联表查询时,受 RLS 限制,当前租户无法访问实际的用户数据,导致用户数据为 null,从而触发 500 服务器错误。

解决方案

新增了一个复合外键约束 (tenant_id, user_id),指向 users (tenant_id, id),确保组织-用户关系的租户 ID 与用户的租户 ID 一致。 这在数据库层面强制了正确的租户隔离。