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

許多 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 此時不參與。

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

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

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

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

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

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

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

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

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

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

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

只有兩個驗證都通過：

3. 合併訪客資料 到用戶帳號
4. 作廢該訪客 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 實現訪客模式就是這簡單三步：

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

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