如何实现游客模式（匿名用户）并转化为 Logto 用户

许多应用允许用户在注册前先体验部分功能，比如购物车、文档草稿或保存偏好。用户期望“游客模式”能开箱即用。

但如果你用 Logto（或任何 OIDC 提供商）做认证，可能会想：怎么处理这些匿名用户？

简短的答案是：Logto 负责认证，你的应用负责游客会话。两者是独立的。

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

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

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

你可能以为 Logto 会有一个“匿名登录”功能。比如：调用 API，拿到 token，无需用户交互。

但 OIDC 不是这样设计的，原因如下：

OIDC 是围绕用户同意构建的。 它的核心目的是验证“这个人是谁？”匿名 token 代表“这是某个人，但不知道是谁”——这违背了初衷。

可以这样理解：

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

游客模式关注的是会话追踪，而不是认证。因此它不属于认证系统的范畴。

其实这反而是件好事。 意味着有了清晰的分工：

• Logto 负责身份（注册、登录、token）
• 应用负责游客会话（身份尚未存在时）

各司其职，各尽其用。

三阶段解决方案#

模式如下：游客 → 认证 → 合并

第 1 阶段：无认证处理游客会话#

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

用户产生实际操作（如加入购物车）时，你的后端：

1. 生成一个游客 ID（如 UUID）
2. 作为 cookie 或 JWT 返回
3. 按 guestId 记录用户操作

保持架构简单。guest_sessions 表包括 guest_id、data、created_at 即可。

第 2 阶段：让用户通过 Logto 登录#

当用户点击“注册”或“登录”按钮时，启动标准 Logto OIDC 流程。

guestId 保持在 cookie/存储中。认证成功后，前端同时拥有：

• 来自 Logto 的 access token（用户身份）
• 之前的 guestId（游客数据）

第 3 阶段：安全合并游客数据到已认证用户#

现在连接数据。用两者调用后端 API：

后端必须校验 两者，再允许合并：

1. 校验 access token → 提取用户 ID。具体做法见 验证 access token。
2. 校验 guestId → 确认这是你后端生成的真实会话。很重要——绝不能直接信任前端传来的 guestId。

只有两者验证都通过后：

3. 合并游客数据到该用户账户
4. 失效游客会话

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

如何通过 token 校验保护合并接口#

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

• 始终校验 access token。 别直接用请求体里的 user id，一定要解码校验 JWT。Logto 的做法见此。
• 始终校验 guestId。 查数据库确认存在且未过期。如果 guestId 用 JWT 签发，校验签名。
• 强制认证。 合并端点必须拒绝无效 access token 的请求。
• 为游客会话设置 TTL。 比如 30 天后清理无主会话（按需求自定时间）。

总结#

用 Logto 实现游客模式，遵循如下简单模式：

1. 游客（你的应用）→ 注册前管理会话
2. 认证（Logto）→ 负责注册和登录
3. 合并（你的应用）→ 将游客数据连接到真实用户

该模式适用于所有 OIDC 提供商，不仅仅是 Logto。核心思想在于：认证与会话追踪是两件事，各自独立，发挥其长处即可。