sid) と ログアウトトークン を利用して、バックチャネル通信によるセッション終了を調整します。異なるセッション ID は、テナント内のユーザーエージェントまたはデバイスごとの個別のセッションを表します。ログアウトトークン は、ログアウト対象のエンドユーザーとセッションを識別します。
バックチャネル通信
バックチャネルログアウト を使用するには、アプリケーションが バックチャネルログアウト URI を公開している必要があります。この URI はテナントサーバーからアクセス可能で、アプリケーションはここで ログアウトトークン を含むリクエストを受信します。アプリケーションがこのリクエストを受け取った場合、トークン内のクレームに一致するローカルのセッション状態をクリアする必要があります。バックチャネル logout を機能させるには、アプリケーションがバックチャネル通信を受信できる必要があります。
OIDC バックチャネル Logout 通信で使用されるトークン
通信がバックチャネル経由で行われる場合、アプリケーションはどのセッションを終了すべきかを判断するために に頼ることはできません。代わりに、サービスは ID トークンと Logout トークンに含まれる共有セッション識別子 (sid) を使用します。
エンドユーザーが login 時に Auth0 で正常に認証されると、 はアクセストークンと ID トークンを発行します。Logout トークンは、logout アクションやセッションの失効などによってセッションが破棄されると生成されます。ID トークンと Logout トークンの両方には、バックチャネル Logout ワークフローを実行するためにアプリケーションが必要とするクレームが含まれています。クレームの詳細については、JSON Web Token Claims をお読みください。

- Login - ユーザー認証時に、Auth0 テナントは
sidを ID トークンに追加します。 - Login - アプリケーションは受け取ったセッション識別子を独自のセッションストアに保存し、アプリケーション固有のセッションに関連付けます。
- Logout - IdP は事前に登録された logout コールバック URL を呼び出し、このエンドポイントに Logout トークンを POST します。トークンには、他のパラメーターとともに
user_id(sub) とsidが含まれます。 - Logout - アプリケーションのバックエンドは、OIDC 仕様に従って Logout トークンを検証し、
sidを抽出する必要があります。その後、バックエンドはこのトークンを使用して、その識別子に関連付けられたセッションを特定し、必要に応じて終了できます。
logout が成功した場合に期待されるレスポンスは
HTTP 200 です。HTTP 400 (不正または誤って解釈された request) を受け取った場合は、トラブルシューティングのヒントを活用できます。詳細については、バックチャネル Logout を設定する をお読みください。仕組み
このサンプルユースケースでは、複数のアプリケーションで バックチャネルログアウト がどのように機能するかを示します。
- アプリケーションの設定時に、アプリケーション A は バックチャネルログアウト URI を Auth0 に登録します。
-
アプリケーションの設定時に、アプリケーション B は バックチャネルログアウト URI を Auth0 に登録します。
OIDC バックチャネルログアウト URL は、次の要件を満たす必要があります。
- IdP からアクセスできること
- TLS で暗号化されたエンドポイントを使用すること
- ログアウトトークン を検証する
- エンドユーザーの login 時に、ユーザーはアプリケーション A にアクセスするため Auth0 で認証されます。
-
Auth0 は
sidを含む ID トークンをアプリケーション A に送信します。詳しくは、ID Token Structure を参照してください。 - ユーザーはアプリケーション B にアクセスするため Auth0 で認証されます。
-
Auth0 は同じ
sidを含む ID トークンをアプリケーション B に送信します。アプリケーションでは、このセッション情報を保存する必要があります。 - logout 時に、アプリケーション A または他のエンティティがフロントチャネルで logout を開始します。
- Auth0 はセッションクッキーを通じて Auth0 セッション層を終了します。
- Auth0 はアプリケーション A の バックチャネルログアウト URI を呼び出し、ログアウトトークン を POST します。
- アプリケーション A は ログアウトトークン を検証し、セッションを終了します。
- Auth0 はアプリケーション B の バックチャネルログアウト URI を呼び出し、ログアウトトークン を POST します。
- アプリケーション B は ログアウトトークン を検証し、セッションを終了します。
サンプルトークン
Auth0 で ログアウトトークン として使用するには、アプリケーションが を解析し、検証できる必要があります。詳しくは、JSON Web Tokens を検証するをご覧ください。 アプリケーションでトークンを検証してデコードすると、その内容は次の例のようになります。JSON
Auth0 SDK
完全なサンプルと本番環境向けのコードは、express-openid-connect SDK の バックチャネル ログアウトの例 セクションにすでに含まれています。実装例
セッションストレージ
このセッションストレージの例は Node (Express) で構築されており、Express OpenID Connect Web App Sample をベースにしています。 アプリケーションの sessions タブで、Logout Token を受け取るよう設定したルートを公開します。トークンを検証し、ユーザーセッションを終了します。この例では、デモ目的でインメモリのセッションストアを使用しています。
routes/index.js
middlewares/validateLogoutToken.js
ログアウトトークンストア
トークン保存の一般的な方法として、セッションストアモデルの代わりにログアウトストアを定義する方法があります。アプリケーションは、永続化層に ログアウトトークン のコレクションを保持します。 アプリケーションが認証状態を確認する必要があるたびに、ログアウトトークンストアを照会して、セッションがまだ有効かどうかを確認します。ログアウトストアは、必要な情報だけを残すために、古い情報を定期的に削除します。
セキュリティに関する考慮事項
Back-Channel Logout Tokens はインターネット経由で配信されるため、それらを受信するコールバックエンドポイントは、信頼性と安全性を確保するためにベストプラクティスに従う必要があります。以下の推奨事項は網羅的なものではないため、実際のデプロイや運用状況に応じて適宜判断する必要があります。以下の一覧では、Back-Channel Logout Tokens を処理するアプリを「アプリ」と呼びます。- アプリは、後で Back-Channel Logout token を受信した際に参照できるよう、ユーザーの login 時に受信したセッション ID (
sidclaim) を保存できなければなりません。 - アプリは、受信した token を JWT 検証のベストプラクティス に従って検証しなければなりません。
- アプリは、信頼できるテナントによって発行された token のみを受け入れなければなりません。悪意のある第三者が他の Auth0 テナントによって発行された token を送信しようとする可能性があるため、そのような試みは拒否しなければなりません。
- アプリは、アプリが認識できる
sid値 (セッション ID) を含む token のみを受け入れなければなりません。無効なセッション ID (期限切れまたは未認識) を含む token は拒否しなければなりません。 - アプリは、コールバックエンドポイントを TLS 経由でのみ公開しなければなりません。暗号化されていない通信チャネルは許可されません。
- アプリは、公開されている 送信元 IP アドレス の一覧からの request のみを受け入れることが推奨されます。
- アプリは、監視、ログ、およびレート制限に関する一般的なベストプラクティスに従うことが推奨されます。ただし、これらの詳細はこのドキュメントの範囲外です。
- アプリは、古くなったセッションや期限切れのセッションを定期的に削除することが推奨されます。
- endpoint アドレスに変更がある場合は、ログアウトトークンs が常に正しい Back-Channel Logout Callback URL に配信されるよう、テナントの設定と同期しなければなりません。