如何使用 Logto 实现访客模式（匿名用户）

许多应用允许用户在注册之前体验功能。例如购物车、文档草稿或已保存的偏好设置。用户期待这些“访客模式”能够直接使用。

但是如果你使用 Logto（或任何 OIDC 提供商）进行认证，你可能会疑问：如何处理这些匿名用户？

简单来说：Logto 负责认证，你的应用负责管理访客会话。两者是独立的。

在本文中，我会向你展示一个简单的三阶段模式，用 Logto 实现访客模式。你将学到如何：

• 在后端管理访客会话
• 让访客通过 Logto 注册
• 将访客数据合并到真实用户账号

为什么 Logto 没有“匿名登录”#

你可能期望 Logto 有一个“匿名登录”功能。比如调用一个 API，获取一个令牌，无需用户交互。

但这不是 OIDC 的工作方式。原因如下：

OIDC 围绕用户同意而构建。 整个目的就是验证“这个人是谁？” 匿名令牌意味着“这只是某个人，但我们不知道是谁”——这违背了初衷。

换句话说：

• 认证 = 验证身份（“你是谁？”）
• 会话追踪 = 记录操作（“你做了什么？”）

访客模式关注的是会话追踪，不是认证。因此它不属于你的认证系统。

这其实是好消息。 这意味着你可以做到职责清晰分离：

• Logto 负责身份（注册、登录、令牌）
• 你的应用负责访客会话（身份存在之前）

让每个系统都做自己应做的事。

三阶段解决方案#

这个模式是：Guest → Auth → Merge

阶段 1：无认证地处理访客会话#

你的后端负责创建和管理访客会话。此时 Logto 尚未介入。

当用户执行有意义的操作（比如加入购物车）时，你的后端需：

1. 生成一个访客 ID（如 UUID）
2. 通过 cookie 或 JWT 返回至前端
3. 用这个访客 ID 存储用户的操作

保持简单。一个包含 guest_id、data 和 created_at 的 guest_sessions 表就够用了。

阶段 2：让用户用 Logto 登录#

当用户点击“注册”或“登录”时，触发标准 Logto OIDC 流程。

此过程中，访客 ID 保留在 cookie/存储中。认证成功后，你的前端拥有：

• 来自 Logto 的访问令牌（用户身份）
• 之前的访客 ID（访客数据）

阶段 3：安全地将访客数据合并到已认证用户#

现在把数据串联起来。用这两者调用你的后端 API：

你的后端必须验证两个令牌后才能合并数据：

1. 验证 access token → 提取用户 ID。如何配合 Logto 进行操作见验证访问令牌。
2. 验证 guest ID → 确认它是你的后端签发的真实会话。很重要——永远不要直接相信客户端传来的 guest ID。

只有当两项验证都通过后：

3. 合并访客数据到用户账号
4. 使访客会话失效

数据合并逻辑根据你的业务来定。购物车？合并商品。文档草稿？转移所有权。你来决定。

如何通过令牌验证保障合并接口安全#

这个合并接口属于敏感操作，需要注意：

• 必须验证 access token。 不要只是从请求体里读取用户 ID。要解析并校验 JWT。这里是如何和 Logto 配合的指南。
• 必须验证 guest ID。 确认其存在于数据库且未过期。若以 JWT 方式签发，需校验签名。
• 强制登录。 合并接口必须拒绝任何没有有效 access token 的请求。
• 设定访客会话 TTL。 超过 30 天（或适合你应用的周期）未用的会话应被清理。

总结#

Logto 下的访客模式遵循简单模式：

1. 访客（你的应用）→ 管理注册前的会话
2. 认证（Logto）→ 处理注册与登录
3. 合并（你的应用）→ 将访客数据同步给真实用户

这个模式适用于任何 OIDC 提供商，不只是 Logto。核心思想是：认证与会话追踪互不干扰。各司其职，系统才能最优工作。