如何使用 Logto 實現訪客模式（匿名用戶）

許多應用程式會讓用戶在註冊前先體驗功能。例如購物車、文件草稿或保存偏好設定。用戶期望 「訪客模式」 能直接使用。

但如果你用 Logto（或任何 OIDC 服務商）來做驗證，你可能會想：那該如何處理這些匿名用戶？

簡短答案：Logto 負責驗證，你的應用程式負責訪客會話。這兩者是分開處理的。

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

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

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

你也許會希望 Logto 有 「匿名登入」 功能。像是：呼叫 API、獲取 token，不需要用戶互動。

但這不是 OIDC 的運作方式。原因如下：

OIDC 的設計核心是用戶同意。 全部的目的是要驗證「這個人是誰？」所謂匿名 token 就等於「這是某個人，但不知道他是誰」——這就違反宗旨了。

換個方式想：

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

訪客模式是會話追蹤、不是驗證。所以它不應該放在驗證系統裡面。

其實這是好事。 代表你可以把責任清楚切開：

• Logto 負責身分（註冊、登入、token）
• 應用程式負責訪客會話（身分產生前）

各自做好各自專精的部分。

三階段解法#

模式如下：訪客 → 驗證 → 合併

第一階段：沒驗證也能用的訪客會話#

你的後端會建立並管理訪客會話。這時 Logto 尚未介入。

當用戶做出有意義動作（例如加到購物車），後端就會：

1. 產生一組訪客 ID（例如 UUID）
2. 用 cookie 或 JWT 存給前端
3. 以這組訪客 ID 儲存用戶行為資料

保持簡單，一張 guest_sessions 表格有 guest_id、data、created_at 就夠了。

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

當用戶點擊「註冊」或「登入」，就開始標準 Logto OIDC flow。

這時候訪客 ID 依然保存在 cookie 或 local storage。驗證完之後，前端就會同時有：

• Logto 提供的 access token（用戶身分）
• 剛才的 guest ID（訪客資料）

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

這時要串接兩邊。請呼叫你的後端 API，把兩者帶過去：

後端必須要驗證 兩種 token：

1. 驗證 access token → 取得用戶 ID。如何和 Logto 驗證，請參閱 驗證 access token 。
2. 驗證 guest ID → 必須確認是你的後端先產生的訪客會話。極重要——千萬不要直接相信前端傳來的 guest ID，一定要驗證過。

通過兩者驗證才能：

3. 合併訪客資料 到用戶帳號
4. 失效該訪客會話

合併邏輯依照商業需求決定。購物車？合併商品。文件草稿？轉手歸屬。看你需求而定。

如何確保合併 API 的安全驗證#

合併 API 是高風險操作，務必注意：

• 永遠驗證 access token。 不要只從請求 body 讀 user ID。要解碼、驗證 JWT。Logto 驗證方式在這裡。
• 永遠驗證 guest ID。 檢查是否存在資料庫且未過期。若是 JWT，驗證簽名。
• 必須驗證身分。 合併 API 沒 token 就必須拒絕請求。
• 訪客會話要有期限（TTL）。 例如 30 天未用就自動清理，可以依需求自訂。

小結#

用 Logto 實作訪客模式有簡單三步：

1. Guest（你的 app）→ 用戶註冊前管理 session
2. Auth（Logto）→ 包辦註冊和登入
3. Merge（你的 app）→ 接軌訪客資料到真用戶

此模式適用所有 OIDC 服務商，不只是 Logto。重點是：驗證和會話追蹤是獨立責任。各自專精，才最安全。