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

好多應用程式都會俾用戶喺註冊之前先試用部分功能，例如購物車、文件草稿或者已儲存的偏好設定。用戶都預期呢啲「訪客模式」可以直接用。

但如果你用 Logto（或者任何 OIDC 供應商）去做認證，你可能會問：點樣處理呢啲匿名用戶？

簡單講：Logto 負責認證，你的 app 負責訪客會話。兩者各司其職。

本文會介紹一個簡單而有效的三階段模式喺 Logto 上實現訪客模式。你會學到點樣：

• 仲管理你後端的訪客會話
• 俾訪客用 Logto 註冊
• 將訪客數據合併到真正的用戶帳戶

點解 Logto 冇「匿名登入」功能#

你可能估到 Logto 應該會有個「匿名登入」功能。例如 call 一個 API 攞個 token，都唔洗用戶互動。

但 OIDC 就唔係咁做。原因如下：

OIDC 係圍住用戶同意而起。 目的就係驗證「呢個人係邊個？」匿名 token 等於「有個人，但唔知係邊個」——咁就冇咗認證嘅意義。

咁樣諗：

• 認證（Authentication） = 證明身份（「你係邊個？」）
• 會話追蹤（Session tracking） = 記低動作（「你做咗啲乜？」）

訪客模式係會話追蹤，唔係認證。所以唔應該放入你嘅認證系統入面。

其實咁樣更加好。 因為你可以清楚分工：

• Logto 負責身份（註冊、登入、發 token）
• 你個 app 負責訪客會話（身份未有之前）

各自做返自己最擅長嘅嘢。

三階段方案#

模式就係：Guest → Auth → Merge

階段一：無認證下處理由訪客會話#

你嘅後端會創建和管理訪客會話，呢個時候 Logto 都未參與。

當某個用戶做咗有意義動作（好似加落購物車），你個後端：

1. 生成個 guest ID（例如 UUID）
2. 用 cookie 或 JWT 傳返俾前端
3. 將用戶動作儲存在呢個 guest ID 之下

唔駛複雜，單單一個 guest_sessions 表，裝 guest_id、data 同 created_at 就夠。

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

用戶撳「註冊」或「登入」時，啟動標準 Logto OIDC 流程。

流程入面，guest ID 一路留喺 cookie／storage。成功通過認證後，你個前端已有：

• Logto 發出嘅 access token（身份）
• 之前帶住嘅 guest ID（訪客資料）

階段三：安全合併訪客數據到授權用戶#

終於可以連上兩邊。call 你後端 API，攞齊兩樣：

你個後端一定要驗證兩個 token：

1. 驗 access token → 拎出 user ID。參考 驗證 access tokens 睇下 Logto 點搞。
2. 驗 guest ID → 係咪你後端發出真訪客會話。呢步好重要——千祈唔好直接信客戶端傳上嚟嘅 guest ID。

兩個都通過：

3. 合併訪客數據 去真正用戶帳戶
4. 註銷訪客會話

至於點合併要睇你自己嘅業務需要。購物車就合埋購物項目，文件草稿就過戶到用戶名下，等等。

點樣通過 token 驗證保障合併接口安全#

合併 endpoint 係敏感操作，要留意以下：

• 一定要驗 access token。 千萬唔好淨係用 request body 個 user ID，一定要 decode 同驗 JWT。可以參考 Logto 文件。
• 一定要驗 guest ID。 睇下 database 裏面有冇，以及有冇過期。如果係 JWT，驗埋簽名。
• 一定要用戶登入認證。 無 access token 嘅 request 要 reject。
• 幫訪客會話設個 TTL。 超過 30 日（或者你覺得合理嘅時間）就自動清除。

小結#

Logto 訪客模式只係跟住簡單 pattern：

1. Guest（你 app）→ 註冊前自己管理會話
2. Auth（Logto）→ 處理身份認證
3. Merge（你 app）→ 訪客數據歸入用戶

呢個做法通用於任何 OIDC provider，唔只 Logto。重點就係：身份認證同會話追蹤係分開的。各自做返自己擅長的野。