繁體中文（香港）

訪客模式
匿名用戶
用戶轉換

如何實現訪客模式（匿名用戶）並轉換為 Logto 用戶

了解如何使用三階段模式實現訪客模式並轉換為 Logto 用戶：管理訪客 session、以 OIDC 認證、並安全地合併訪客資料到用戶帳號。

Yijun

Developer

1/9/2026

Stop wasting weeks on user auth

Launch secure apps faster with Logto. Integrate user auth in minutes, and focus on your core product.

Get started

許多 app 讓用戶在註冊前先試用功能，例如購物車、文件草稿或儲存偏好。用戶普遍期望這種「訪客模式」可正常運作。

但如果你用 Logto（或任何 OIDC provider）來處理身份認證，你可能會想：應該如何處理這些匿名用戶？

簡短的答案是：Logto 處理身份認證，你的 app 負責訪客 session。這是兩個不同的部分。

在本文中，我會用一個簡單的三階段模式教你如何用 Logto 實現訪客模式。你會學到如何：

在後端管理訪客 session
讓訪客通過 Logto 註冊
將訪客資料合併到真正的用戶帳號

為什麼 Logto 沒有「匿名登入」

你可能期望 Logto 提供「匿名登入」功能，也就是調用一個 API 就能取得 token，完全無需用戶互動。

但 OIDC 並不是這樣運作的。原因如下：

OIDC 本質講求用戶同意。 核心目的是要確定「這個人是誰？」一個匿名 token 就代表「某個人，但我們不知是誰」——這就違背了初衷。

可以這樣理解：

身份認證 = 證明身份（「你是誰？」）
session 追蹤 = 記錄行為（「你做了什麼？」）

訪客模式屬於 session 追蹤，不是身份認證。這部分不該交由認證系統負責。

其實這對你更有利。 這樣可以劃分很清晰：

Logto 處理身份（註冊、登入、token）
你的 app 處理訪客 session（身份產生前）

讓每個系統專注於最擅長的事情。

三階段方案

這個模式是：Guest → Auth → Merge

階段一：無須認證處理訪客 session

你的後端會產生和管理訪客 session。Logto 此時不參與。

當用戶有實際行動（例如加入購物車），後端會：

產生一個 guest ID（例如 UUID）
用 cookie 或 JWT 返回 guest ID
以 guest ID 儲存用戶行為記錄

其實很簡單，只需一個 guest_sessions 資料表，包括 guest_id、data 和 created_at 即可。

階段二：讓用戶用 Logto 登入

當用戶點擊「註冊」或「登入」時，觸發 Logto OIDC 標準流程。

這期間，guest ID 依然保留在 cookie／本地存儲。認證成功後，前端會同時擁有：

Logto 發出的 access token（用戶身份）
原先的 guest ID（訪客資料）

階段三：安全地將訪客資料合併到認證用戶

現在要將兩者連接起來。調用後端 API，並同時送出：

後端必須同時驗證 兩個 token，才可合併：

驗證 access token → 取出用戶 ID。參考驗證 access token 學習 Logto 的驗證方法。
驗證 guest ID → 確認是你後端簽發的有效訪客 session。這點很重要——千萬不要直接信任用戶端傳來的 guest ID。

只有兩個驗證都通過：

合併訪客資料 到用戶帳號
作廢該訪客 session

合併資料的邏輯就因不同業務而異。購物車？合併商品項目。文件草稿？換擁有者。你自行決定。

如何以 token 檢查保護你的 merge endpoint

merge endpoint 是敏感操作，要注意幾點：

**一定要驗證 access token。**不要只從 body 讀用戶 ID。記得解碼及驗證 JWT。這裡有 Logto 用法。
**一定要驗證 guest ID。**檢查它必須存在於數據庫、沒過期。如用 JWT 發出，還要驗證簽名。
**要 require authentication。**merge endpoint 必須拒絕沒帶有效 access token 的請求。
**設置 guest session TTL。**例如 30 天後自動清理廢棄 session（依 app 需要設定）。

總結

使用 Logto 實現訪客模式就是這簡單三步：

Guest（你的 app） → 管理用戶註冊前的 session
Auth（Logto） → 處理註冊與登入
Merge（你的 app） → 訪客資料與用戶帳號連接

這個模式其實任意 OIDC provider 都用得上，不只 Logto。重點是：身份認證與 session 追蹤本來就是兩回事，就讓各系統做自己最擅長的事吧。

為什麼 Logto 沒有「匿名登入」#

三階段方案#

階段一：無須認證處理訪客 session#

階段二：讓用戶用 Logto 登入#

階段三：安全地將訪客資料合併到認證用戶#

如何以 token 檢查保護你的 merge endpoint#

總結#

為什麼 Logto 沒有「匿名登入」#

三階段方案#

階段一：無須認證處理訪客 session#

階段二：讓用戶用 Logto 登入#

階段三：安全地將訪客資料合併到認證用戶#

如何以 token 檢查保護你的 merge endpoint#

總結#

為什麼 Logto 沒有「匿名登入」

三階段方案

階段一：無須認證處理訪客 session

階段二：讓用戶用 Logto 登入

階段三：安全地將訪客資料合併到認證用戶

如何以 token 檢查保護你的 merge endpoint

總結

為什麼 Logto 沒有「匿名登入」

三階段方案

階段一：無須認證處理訪客 session

階段二：讓用戶用 Logto 登入

階段三：安全地將訪客資料合併到認證用戶

如何以 token 檢查保護你的 merge endpoint

總結