Logtoでゲストモード（匿名ユーザー）を実装する方法

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

しかし、認証に Logto （もしくは他の OIDC プロバイダー）を使っている場合、「こういった匿名ユーザーをどう扱えば良いのか？」と疑問に思うかもしれません。

端的に言えば：「Logto は認証を、あなたのアプリはゲストセッションを扱います」。この 2 つは別々の仕組みです。

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

• バックエンドでのゲストセッションの管理
• ゲストの Logto 経由でのサインアップ
• ゲストデータを本物のユーザーアカウントに統合する方法

なぜ Logto には「匿名ログイン」がないのか#

Logto には「匿名ログイン」機能があるのでは、と期待したかもしれません。たとえば「API を叩くとトークンが手に入って、ユーザー操作が不要」な感じ。

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

OIDC はユーザーの同意の上に成り立っています。 目的は「この人物は誰か？」と確認することです。匿名トークンは「誰かがいるが、誰かはわからない」という意味になります——これでは本来の意味が成り立ちません。

このように考えてみましょう：

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

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

これはむしろ良いニュースです。 きちんと役割が分かれるからです：

• Logto が身元確認（サインアップ・サインイン、トークン）を担当
• あなたのアプリがゲストセッション（まだ身元がない段階）を担当

それぞれが設計された役割をこなしましょう。

3 段階ソリューション#

パターンはこうです：ゲスト → 認証 → 統合

フェーズ 1：認証なしでゲストセッションを管理する#

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

ユーザーが意味のあるアクション（例：カートに商品追加）をすると、バックエンドは：

1. ゲスト ID（例：UUID）を生成する
2. それをクッキーや JWT として返す
3. この guest ID に基づき、ユーザーの操作内容を記録する

シンプルで良いです。guest_sessions テーブルに guest_id, data, created_at があれば十分です。

フェーズ 2：Logto でユーザーサインイン#

ユーザーが「サインアップ」や「サインイン」をクリックしたら、標準の Logto OIDC フローを起動します。

ゲスト ID はこの過程でクッキー・ストレージに維持されます。認証に成功すると、フロントエンドは：

• Logto からのアクセストークン（ユーザーの身元）
• 以前からのゲスト ID（ゲストデータ） の両方を保持しています。

フェーズ 3：ゲストデータを認証済みユーザーへ安全に統合#

2 つを繋げます。両方を持ってバックエンド API へリクエスト：

バックエンドが 両方 のトークンを必ず検証してください：

1. アクセストークンを検証 → ユーザー ID を抽出します。アクセストークンの検証方法（Logto ドキュメント） も参照。
2. ゲスト ID を検証 → それが あなたのバックエンドが発行した正当なゲストセッション であることを確認します。これが極めて重要——クライアントが送ってきた guest ID をそのまま信用しないでください。

両方とも検証が終わったら：

3. ゲストデータをユーザーアカウントへ統合
4. ゲストセッションを失効させる

マージ処理の具体例はあなたのビジネスロジック次第です。ショッピングカートならアイテムを結合、ドキュメント下書きならオーナーシップ移譲など。

トークン検証でマージ用エンドポイントを安全にする方法#

マージ用エンドポイントはデリケートな操作です。注意点をまとめます：

• 必ずアクセストークンを検証すること。 リクエストボディからユーザー ID を読まず、JWT をデコードして検証してください。Logto での方法はこちら。
• 必ずゲスト ID を検証すること。 データベースに存在し、期限切れでないかをチェック。JWT なら署名も検証。
• 認証を必須にすること。 正当なアクセストークンのないリクエストは拒否してください。
• ゲストセッションに有効期限（TTL）を設ける。 放置されたセッションは 30 日後（あるいはアプリ方針に合わせて）クリーンアップしましょう。

まとめ#

Logto を使ったゲストモードはシンプルなパターンに従います：

1. ゲスト（あなたのアプリ）→ サインアップ前のセッション管理
2. 認証（Logto）→ サインアップ・サインイン処理
3. 統合（あなたのアプリ）→ ゲストデータを本物のユーザーへ統合

このパターンは Logto 以外のどんな OIDC プロバイダーでも通用します。ポイントは「認証」と「セッション管理」は別物だということ。それぞれの仕組みに役割を任せましょう。