メインコンテンツまでスキップ

サインアウト

Logto（OIDC アイデンティティプロバイダー (IdP) として）のサインアウトは、次の両方を含みます：

  • 集中管理された Logto セッション（Logto ドメイン配下のブラウザ Cookie）
  • 分散されたクライアント側の認証状態（各アプリのトークンやローカルアプリセッション）

サインアウトの挙動を理解するには、この 2 層を分けて考え、グラント (grant) がどのようにそれらをつなぐかを見ると分かりやすいです。

コア概念​

Logto セッションとは？​

Logto セッションは、Logto によって管理される集中管理されたサインイン状態です。認証 (Authentication) に成功した後に作成され、Logto ドメイン配下の Cookie で表現されます。

セッション Cookie が有効な場合、同じ Logto テナントを信頼する複数のアプリ間でサイレント認証（シングルサインオン (SSO)）が可能です。

有効なセッションが存在しない場合、Logto はサインインページを表示します。

グラント (grant) とは？​

グラント (grant) とは、特定のユーザーとクライアントアプリケーションの組み合わせに対する認可 (Authorization) 状態を表します。

  • 1 つの Logto セッションは、複数のクライアントアプリのグラント (grant) を持つことができます。
  • グラント (grant) は発行されたトークンと関連付けられます。
  • このドキュメントセットでは、グラント (grant) をアプリ横断の認可 (Authorization) 単位として扱います。

セッション、グラント (grant)、クライアント認証状態の関係​

  • Logto セッション は集中管理された SSO 体験を制御します。
  • クライアントのローカルセッション / トークン は、各アプリが現在ユーザーをサインイン済みとして扱うかどうかを制御します。
  • グラント (grant) は、アプリ固有の認可 (Authorization) 状態を表現することで、この 2 つの世界をつなぎます。

サインインの振り返り（なぜサインアウトが多層的なのか）​

アプリ / デバイス間のセッショントポロジー​

ユーザーが同じブラウザから複数のアプリにサインインした場合、それらのアプリは同じ Logto セッション Cookie を再利用でき、SSO が適用されます。

分離されたセッション Cookie（異なるデバイス / ブラウザ）​

異なるブラウザ / デバイスは異なる Logto Cookie を保持するため、サインインセッション状態は分離されます。

サインアウトの仕組み​

1) クライアント側のみのサインアウト​

クライアントアプリが自身のローカルセッションやトークン（ID / アクセス / リフレッシュトークン）をクリアします。これにより、そのアプリのローカル状態のみでユーザーがサインアウトされます。

  • Logto セッションは引き続き有効な場合があります。
  • 同じ Logto セッション配下の他のアプリでは SSO が継続される場合があります。

2) Logto でのセッション終了（現行 Logto 実装でのグローバルサインアウト）​

集中管理された Logto セッションをクリアするには、アプリがユーザーをエンドセッションエンドポイントへリダイレクトします。例：

https://{your-logto-domain}/oidc/session/end

現行の Logto SDK の挙動：

  1. signOut() は /session/end へリダイレクトします。
  2. その後 /session/end/confirm へ遷移します。
  3. デフォルトの確認フォームが自動で logout=true をポストします。

このため、現行 SDK のサインアウトは グローバルサインアウト として扱われます。

グローバルサインアウト時に何が起こるか​

グローバルサインアウト中：

  • 集中管理された Logto セッションが取り消されます。
  • 関連するアプリのグラント (grant) はアプリごとの認可 (Authorization) 状態に応じて処理されます：
    • offline_access が 付与されていない 場合、関連グラント (grant) は取り消されます。
    • offline_access が 付与されている 場合、エンドセッションではグラント (grant) は取り消されません。
  • offline_access の場合、リフレッシュトークンやグラント (grant) はグラント (grant) の有効期限まで有効です。

グラント (grant) の有効期間と offline_access の影響​

  • デフォルトの Logto グラント (grant) TTL は 180 日 です。
  • offline_access が付与されている場合、エンドセッションではそのアプリのグラント (grant) はデフォルトで取り消されません。
  • そのグラント (grant) に紐づくリフレッシュトークンチェーンは、グラント (grant) の有効期限まで（または明示的に取り消されるまで）継続できます。

フェデレーテッドサインアウト：バックチャネルログアウト​

アプリ間の一貫性のため、Logto は バックチャネルログアウト をサポートしています。

ユーザーが 1 つのアプリからサインアウトすると、Logto は同じセッションに参加しているすべてのアプリに対し、登録済みのバックチャネルログアウト URI へログアウトトークンを送信して通知できます。

アプリのバックチャネル設定で Is session required が有効な場合、ログアウトトークンには Logto セッションを識別する sid が含まれます。

一般的なフロー：

  1. ユーザーが 1 つのアプリからサインアウトを開始
  2. Logto がエンドセッションを処理し、登録済みのバックチャネルログアウト URI へログアウトトークンを送信
  3. 各アプリがログアウトトークンを検証し、自身のローカルセッション / トークンをクリア

Logto SDK におけるサインアウト方法​

  • SPA および Web：client.signOut() はローカルトークンストレージをクリアし、Logto のエンドセッションエンドポイントへリダイレクトします。ポストログアウトリダイレクト URI を指定することも可能です。
  • ネイティブ（React Native / Flutter を含む）：通常はローカルトークンストレージのみをクリアします。セッションレス WebView のため、Logto のブラウザ Cookie をクリアすることはありません。
注記:

セッションレス WebView をサポートしないネイティブアプリや、emphasized 設定を認識しない場合（React Native や Flutter SDK を利用した Android アプリなど）、認証リクエスト時に prompt=login パラメータを渡すことで、毎回サインイン画面を強制表示できます。

毎回再認証を強制する​

高セキュリティな操作には、認証リクエストに prompt=login を含めて SSO をバイパスし、毎回資格情報の入力を強制できます。

リフレッシュトークン（offline_access）を要求する場合は、consent も含めて prompt=login consent とします。

一般的な組み合わせ設定：

prompt=login consent

よくある質問 (FAQs)​

バックチャネルログアウト通知が届きません​

  • Logto ダッシュボードでバックチャネルログアウト URI が正しく登録されているか確認してください。
  • アプリが同じユーザー / セッションコンテキストでアクティブなサインイン状態であることを確認してください。

OIDC バックチャネルログアウトの理解