sid)を活用して、バックチャネル通信を介してセッションの終了を調整します。異なるセッションIDは、テナント内のユーザーエージェントまたはデバイスの個々のセッションを表します。ログアウトトークンは、ログアウトするエンドユーザーとセッションを識別します。
バックチャネル通信
バックチャネルログアウトが機能するためには、アプリケーションがバックチャネル通信を受信できなければなりません。
OIDCバックチャネルログアウト通信のトークン
sid)に依存します。
エンドユーザーがログイン時にAuth0で正常に認証されると、認可サーバーはアクセストークンとIDトークンを発行します。ログアウトトークンは、ログアウトアクションやセッションの取り消しなどによってセッションが破棄されたときに生成されます。IDトークンとログアウトトークンの両方に、バックチャネルログアウトワークフローを容易にするためにアプリケーションが必要とするクレームが含まれています。クレームの詳細については、「JSON Webトークンクレーム」をお読みください。

- ログイン - ユーザー認証中に、Auth0テナントはIDトークンに
sidを追加します。 - ログイン - アプリケーションは、受信したセッション識別子を独自のセッションストアに保存し、それをアプリケーション固有のセッションに関連付けます。
- ログアウト - IdPは、事前に登録されたログアウトコールバックURLを呼び出し、ログアウトトークンをこのエンドポイントに投稿します。トークンには、
user_id(sub)とsidおよびその他のパラメーターが含まれます。 - ログアウト - アプリケーションのバックエンドは、OIDC仕様に従ってログアウトトークンを検証し、
sidを抽出する必要があります。その後、バックエンドはこのトークンを使用して、識別子に関連付けられたセッションを見つけ、必要に応じてセッションを終了できます。
ログアウトの成功時に予期される応答は
HTTP 200です。HTTP 400を受け取った場合は、要求が正しくないか、誤って解釈されたと考えられるため、トラブルシューティングのヒントを参考にしてください。詳細については、「バックチャネルログアウトを構成する」をお読みください。仕組み

- アプリケーションの構成中に、アプリケーションAはAuth0にバックチャネルログアウトURIを登録します。
-
アプリケーションの構成中に、アプリケーションBはAuth0にバックチャネルログアウトURIを登録します。
OIDCのバックチャネルログアウトのURLは、以下の条件を満たさなければなりません。
- IdPからアクセスできる
- TLS暗号化されたエンドポイントを使用している
- ログアウトトークンを検証する
- エンドユーザーのログイン時に、ユーザーはAuth0で認証してアプリケーションAにアクセスします。
-
Auth0は、
sidを含むIDトークンをアプリケーションAに送信します。詳細については、「IDトークンの構造」をお読みください。 - ユーザーはAuth0で認証してアプリケーションBにアクセスします。
-
Auth0は同じ
sidを含むIDトークンをアプリケーションBに送信します。アプリケーションはセッション情報を保存しなければなりません。 - ログアウト中に、アプリケーションAまたは他のエンティティがフロントチャネルでログアウトを開始します。
- Auth0はセッションCookieを介してAuth0セッションレイヤーを終了します。
- Auth0はアプリケーションAのバックチャネルログアウトURIを呼び出し、ログアウトトークンを投稿します。
- アプリケーションAはログアウトトークンを検証し、セッションを終了します。
- Auth0はアプリケーションBのバックチャネルログアウトURIを呼び出し、ログアウトトークンを投稿します。
- アプリケーションBはログアウトトークンを検証し、セッションを終了します。
サンプルトークン
JSON
Auth0 SDK
実装例
セッションストレージ
この例では、デモの目的でメモリー内セッションストアを使用しています。
JavaScript
JavaScript
ログアウトトークンストア

セキュリティに関する考慮事項
- アプリは、ユーザーログイン時に受信したセッションID (
sidクレーム)を保存し、後でバックチャネルログアウトトークンを受け取ったときに取得できるようにする必要があります。 - アプリは、JWT検証のベストプラクティスに従って、受信したトークンを検証する必要があります。
- アプリは、信頼できるテナントによって発行されたトークンのみを受け入れる必要があります。悪意のある人物が他のAuth0テナントによって発行されたトークンを送信しようとする可能性があります。このような試みは拒否しなければなりません。
- アプリは、アプリが認識する
sid値(セッションID)が含まれている場合にのみトークンを受け入れる必要があります。無効なセッションID(期限切れまたは認識されない)を含むトークンは拒否する必要があります。 - アプリはコールバックエンドポイントをTLS経由でのみ公開する必要があります。暗号化されていない通信チャネルは許可されません。
- アプリは、公開されている送信IPアドレスのリストからの要求のみを受け入れることをお勧めします。
- アプリは、監視、ログ記録、レート制限に関する一般的なベスト プラクティスに従うことが推奨されますが、これらの詳細はこのドキュメントの範囲外です。
- アプリでは、古くなったセッションや期限切れのセッションを定期的にクリーンアップすることをお勧めします。
- ログアウトトークンが常に正しいバックチャネルログアウトコールバックURLに配信されるようにするには、エンドポイントアドレスの変更をテナント構成と同期する必要があります。