ゲストモード（匿名ユーザー）の実装方法と Logto ユーザーへの変換方法

多くのアプリは、ユーザーがサインアップする前に機能を試せるようになっています。ショッピングカート、ドキュメントの下書き、保存済みの設定などがその例です。ユーザーは、この「ゲストモード」が当然のように使えることを期待しています。

しかし Logto（または他の OIDC プロバイダー）で認証している場合、こうした匿名ユーザーをどう扱えばよいのでしょうか？

簡単に言えば：Logto は認証を担当し、あなたのアプリはゲストセッションを管理します。 この2つは別々の役割です。

この記事では、Logto でゲストモードを実装するシンプルな3段階パターンを紹介します。以下を学べます：

• バックエンドでゲストセッションを管理する方法
• ゲストが Logto でサインアップできるようにする方法
• ゲストデータを実際のユーザーアカウントへマージする方法

Logto に「匿名ログイン」機能がない理由#

Logto に「匿名ログイン」機能があることを期待しているかもしれません。たとえば API を呼び出してトークンを取得し、ユーザーの操作を必要としないようなものです。

しかし、OIDC はそういう仕組みではありません。その理由は：

OIDC はユーザーの同意を前提としています。 仕組みの本質は、「この人が誰か？」を明確に認証することです。匿名トークンは「誰かは来たけど、その人が誰か分からない」という意味になり、本来の目的を果たせません。

こう考えてみてください：

• 認証 ＝ 身元を証明すること（「あなたは誰？」）
• セッション管理 ＝ 行動を記録すること（「あなたは何をした？」）

ゲストモードはセッション管理の話であり、認証とは異なります。だから認証システムには含めません。

これは実は良いことです。 明確な分担ができるからです：

• Logto はアイデンティティ管理（サインアップ、サインイン、トークン発行）
• アプリはゲストセッション管理（身元が確定する前）

それぞれの仕組みに専念させましょう。

三段階ソリューション#

基本パターン：Guest → Auth → Merge（ゲスト → 認証 → マージ）

フェーズ1：認証なしでゲストセッションを扱う#

バックエンドがゲストセッションを生成・管理します。この段階では Logto は関与しません。

ユーザーが意味のある操作をしたとき（例：カートに追加）、バックエンドは：

1. ゲスト ID（例：UUID）を生成
2. クッキーまたは JWT として返却
3. このゲスト ID でユーザーの操作データを保存

シンプルで構いません。guest_sessionsテーブルにguest_id、data、created_at カラムがあれば十分です。

フェーズ2：Logto でサインインを許可する#

ユーザーが「サインアップ」や「サインイン」をクリックしたら、通常の Logto OIDC フローを開始します。

ゲスト ID はクッキーやストレージに残したままです。認証が完了すると、フロントエンドが持つのは：

• Logto からのアクセストークン（ユーザー身元）
• 先ほどまで持っていたゲスト ID（ゲストデータ）

フェーズ3：ゲストデータを認証済みユーザーへ安全にマージする#

ここで両者をつなぎます。API で両方を送信します：

バックエンド側では、両方のトークンを検証してください：

1. アクセストークンを検証 → ユーザー ID を抽出。アクセストークンの検証方法はこちら。
2. ゲスト ID を検証 → 本当にあなたのバックエンドが発行したゲストセッションか確認します。これが肝心で、クライアントの guestId を信用しすぎないように。

2つとも有効であれば：

3. ゲストデータをユーザーへ統合
4. ゲストセッションを無効化

統合の具体的なロジックはビジネス用途により異なります。ショッピングカートなら商品の合体、ドキュメント下書きなら所有権の移管、などです。

トークン検証でマージエンドポイントを守る方法#

マージ関連のエンドポイントは特に慎重に設計しましょう：

• 必ずアクセストークンを検証する。リクエストボディの userId を使うだけでなく、JWT を必ずデコード・検証しましょう。Logto の方法はこちら。
• 必ずゲスト ID を検証する。DB に存在し有効期限が切れていないか確認。JWT 方式なら署名検証も。
• 認証必須にする。アクセストークンのないリクエストは拒否します。
• ゲストセッションの TTL（有効期限）を設定する。未使用セッションは30日などで自動削除しましょう。

まとめ#

Logto のゲストモード運用はシンプルな方式です：

1. ゲスト（アプリ）→ ユーザー登録前のセッション管理
2. 認証（Logto）→ サインアップ・サインイン処理
3. マージ（アプリ）→ ゲストデータを正式ユーザーと接続

このパターンは Logto 以外の OIDC プロバイダーでも活用できます。ポイントは「認証」と「セッション管理」は別物、両者それぞれ専念させることです。