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

許多應用程式都允許用戶在註冊前體驗功能，像是購物車、文件草稿或儲存偏好設定。用戶期望所謂的「訪客模式」能順利運作。

但若你使用 Logto（或其他 OIDC 提供者）作為驗證服務，可能會疑惑：這些匿名用戶該怎麼處理？

簡單來說：Logto 負責驗證，你的應用負責訪客會話。這是兩個不同領域。

本文會介紹如何用三階段模式，在 Logto 下實作訪客模式。你將學會如何：

• 在後端管理訪客會話
• 讓訪客透過 Logto 註冊帳號
• 將訪客資料合併到正式用戶帳號

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

你可能以為 Logto 有個「匿名登入」功能，類似：呼叫 API、取得一個令牌，不需用戶互動。

但 OIDC 並不是這樣設計的，其原因如下：

OIDC 以用戶同意為基礎。 它的核心就在於驗證「這個人是誰？」匿名令牌只代表「這是某個人，但我們不知道是誰」——和 OIDC 本意衝突。

換個方式想：

• 驗證（Authentication） = 證明身分（「你是誰？」）
• 會話追蹤（Session tracking） = 記錄行為（「你做了什麼？」）

訪客模式關於會話追蹤，不是驗證身份。因此這部分不屬於你的驗證系統。

這其實是好事。 也就是你可以明確區分：

• Logto 管身分（註冊、登入、頒發令牌）
• 你的應用管訪客會話（尚未有身份前）

讓每個系統只做它應該做的事。

三階段解方#

重點模式：訪客 → 驗證 → 合併

階段一：未驗證前處理訪客會話#

你的後端負責創建與管理訪客會話，Logto 暫時還沒有參與其中。

當用戶執行重要動作（如加入購物車）時，你的後端會：

1. 產生一組 guest ID（如 UUID）
2. 以 cookie 或 JWT 方式回傳給前端
3. 之後所有用戶行為都與這個 guest ID 綁定

保持簡單即可。只要一張 guest_sessions 資料表，欄位包含 guest_id、data 和 created_at 即可。

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

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

此過程中 guest ID 會繼續存在於 cookie 或儲存機制裡。驗證成功後，前端同時持有：

• 從 Logto 取得的 Access Token（具身分）
• 原本的 guest ID（尚未關聯的資料）

階段三：安全合併訪客資料到登錄用戶#

現在把兩者串起來，同時傳給你的後端 API：

後端必須同時驗證兩種憑證，然後才進行資料合併：

1. 驗證 Access Token → 取出用戶 ID。請參考 驗證 Access Token 以 Logto 實作方式。
2. 驗證 guest ID → 確認這真的是你後端發出的有效訪客會話。這很重要——絕不能直接信任前端送來的 guest ID，一定要後端檢查。

僅於兩邊都驗證通過後：

3. 合併訪客資料 進入用戶帳號
4. 註銷該訪客會話

合併邏輯要依你的實際需求決定。若是購物車就合併商品，若是文件草稿則轉移擁有權等。

如何用令牌驗證保護合併端點#

合併接口端點屬於敏感操作，請特別注意：

• 一定要驗證 Access Token。 別單純信任請求裡的用戶 ID。你需要解碼與驗證 JWT。可參考 Logto 驗證 Token 教學。
• 一定要驗證 guest ID。 確認 guest ID 存在且未過期。若發的是 JWT，驗證簽章正確。
• 必須登入才能呼叫。 若沒有有效 Access Token，就要拒絕請求。
• 為訪客會話設定 TTL（存活時間）。 例如 30 天自動清除未合併的過期訪客資料（或依你需求設定）。

總結#

Logto 訪客模式很簡潔：

1. 訪客（你的應用）→ 在用戶註冊前管理會話
2. 驗證（Logto）→ 負責註冊與登入流程
3. 合併（你的應用）→ 把訪客資料關聯到實際用戶

這個架構也適用於任何 OIDC 服務，不只 Logto。最重要的觀念：驗證（Authentication）與會話追蹤（Session tracking）本來就該分工處理，讓各系統發揮其本職。