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

バックチャネルログアウトでは、ユーザーの SSO セッションが終了すると、すべての Relying Party にサーバー間のログアウトトークンが送信され、アプリケーションがそれぞれのセッションを終了できるようになります。

Auth0 は、Enterprise プランのサブスクリプションをご利用のすべてのテナントで、OpenID Connect Back-Channel Logout 1.0 specification をサポートしています。

この仕様では、ID トークン に含まれるセッション ID (sid) と ログアウトトークン を利用して、バックチャネル通信によるセッション終了を調整します。異なるセッション ID は、テナント内のユーザーエージェントまたはデバイスごとの個別のセッションを表します。ログアウトトークン は、ログアウト対象のエンドユーザーとセッションを識別します。

​

バックチャネル通信

バックチャネルログアウト を使用するには、アプリケーションが バックチャネルログアウト URI を公開している必要があります。この URI はテナントサーバーからアクセス可能で、アプリケーションはここで ログアウトトークン を含むリクエストを受信します。アプリケーションがこのリクエストを受け取った場合、トークン内のクレームに一致するローカルのセッション状態をクリアする必要があります。

バックチャネル logout を機能させるには、アプリケーションがバックチャネル通信を受信できる必要があります。

​

OIDC バックチャネル Logout 通信で使用されるトークン

通信がバックチャネル経由で行われる場合、アプリケーションはどのセッションを終了すべきかを判断するために セッションクッキー に頼ることはできません。代わりに、サービスは ID トークンと Logout トークンに含まれる共有セッション識別子 (sid) を使用します。

エンドユーザーが login 時に Auth0 で正常に認証されると、認可サーバー はアクセストークンと ID トークンを発行します。Logout トークンは、logout アクションやセッションの失効などによってセッションが破棄されると生成されます。ID トークンと Logout トークンの両方には、バックチャネル Logout ワークフローを実行するためにアプリケーションが必要とするクレームが含まれています。クレームの詳細については、JSON Web Token Claims をお読みください。

1. Login - ユーザー認証時に、Auth0 テナントは sid を ID トークンに追加します。
2. Login - アプリケーションは受け取ったセッション識別子を独自のセッションストアに保存し、アプリケーション固有のセッションに関連付けます。
3. Logout - IdP は事前に登録された logout コールバック URL を呼び出し、このエンドポイントに Logout トークンを POST します。トークンには、他のパラメーターとともに user_id (sub) と sid が含まれます。
4. Logout - アプリケーションのバックエンドは、OIDC 仕様に従って Logout トークンを検証し、sid を抽出する必要があります。その後、バックエンドはこのトークンを使用して、その識別子に関連付けられたセッションを特定し、必要に応じて終了できます。

logout が成功した場合に期待されるレスポンスは HTTP 200 です。HTTP 400 (不正または誤って解釈された request) を受け取った場合は、トラブルシューティングのヒントを活用できます。詳細については、バックチャネル Logout を設定する をお読みください。

​

仕組み

このサンプルユースケースでは、複数のアプリケーションで バックチャネルログアウト がどのように機能するかを示します。

1. アプリケーションの設定時に、アプリケーション A は バックチャネルログアウト URI を Auth0 に登録します。

2. アプリケーションの設定時に、アプリケーション B は バックチャネルログアウト URI を Auth0 に登録します。

   OIDC バックチャネルログアウト URL は、次の要件を満たす必要があります。

   • IdP からアクセスできること
   • TLS で暗号化されたエンドポイントを使用すること
   • ログアウトトークン を検証する

3. エンドユーザーの login 時に、ユーザーはアプリケーション A にアクセスするため Auth0 で認証されます。

4. Auth0 は sid を含む ID トークンをアプリケーション A に送信します。詳しくは、ID Token Structure を参照してください。

5. ユーザーはアプリケーション B にアクセスするため Auth0 で認証されます。

6. Auth0 は同じ sid を含む ID トークンをアプリケーション B に送信します。アプリケーションでは、このセッション情報を保存する必要があります。

7. logout 時に、アプリケーション A または他のエンティティがフロントチャネルで logout を開始します。

8. Auth0 はセッションクッキーを通じて Auth0 セッション層を終了します。

9. Auth0 はアプリケーション A の バックチャネルログアウト URI を呼び出し、ログアウトトークン を POST します。

10. アプリケーション A は ログアウトトークン を検証し、セッションを終了します。

11. Auth0 はアプリケーション B の バックチャネルログアウト URI を呼び出し、ログアウトトークン を POST します。

12. アプリケーション B は ログアウトトークン を検証し、セッションを終了します。

バックチャネルログアウトの request は非同期キューに入れられ、できるだけ速やかに処理されます。高負荷時には、logout request が実行されるまでにわずかな遅延が生じる場合があるため、この結果整合性に対応できるようアプリケーションを設計してください。

​

サンプルトークン

Auth0 で ログアウトトークン として使用するには、アプリケーションが JWTs を解析し、検証できる必要があります。詳しくは、JSON Web Tokens を検証するをご覧ください。

アプリケーションでトークンを検証してデコードすると、その内容は次の例のようになります。

JSON

{
  "iss": "https://artex-dev.eu.auth0.com/",
  "sub": "auth0|602e93db83fa6f00749a23e6",
  "aud": "TuhNLv7ulXD3RfyLlSMbOvszzwJJFPpO",
  "iat": 1698160928,
  "exp": 1698161048,
  "jti": "44a91215-dfb4-4dfe-a1eb-fcafa911deba",
  "events": {
    "http://schemas.openid.net/event/backchannel-logout": {}
  },
  "trace_id": "81b336a94a4a5707",
  "sid": "375UIp_ID5mCTClIeBEHpXfGwq51tF_L"
}

​

Auth0 SDK

完全なサンプルと本番環境向けのコードは、express-openid-connect SDK の バックチャネル ログアウトの例 セクションにすでに含まれています。

​

実装例

​

セッションストレージ

このセッションストレージの例は Node (Express) で構築されており、Express OpenID Connect Web App Sample をベースにしています。

アプリケーションの sessions タブで、Logout Token を受け取るよう設定したルートを公開します。トークンを検証し、ユーザーセッションを終了します。

この例では、デモ目的でインメモリのセッションストアを使用しています。

routes/index.js

const express = require('express');
const router = express.Router();
const { requiresAuth } = require('express-openid-connect');

// ログアウトトークンを検証するミドルウェア
const requiresValidLogoutToken = require('../middlewares/validateLogoutToken');

// ユーザーセッションを削除するヘルパー関数
const deleteUserSessions = require('../utils/sessions');

// バックチャネルログアウトトークンを受信する新しいルート
// Auth0 Management Dashboard の Application -> Sessions タブで
// 設定する必要があります
router.post(
  '/backchannel-logout',
  requiresValidLogoutToken,
  function (req, res, next) {
    // この時点でログアウトトークンは有効です（requiresValidLogoutToken ミドルウェアによる検証済み）
    // リクエストオブジェクトからアクセスできます: req.logoutToken

    // ユーザーセッションを削除してログアウトさせる
    deleteUserSessions(
      req.app.locals.sessionStore,
      req.logoutToken.sub,
      req.logoutToken.sid
    );

    res.sendStatus(200);
  }
);

router.get('/', function (req, res, next) {
  res.render('index', {
    title: 'Auth0 Webapp sample Nodejs',
    isAuthenticated: req.oidc.isAuthenticated(),
    headline: process.env.APP_NAME,
    backgroundColor: process.env.BACKGROUND_COLOR,
    baseURL: process.env.BASE_URL,
  });
});

router.get('/profile', requiresAuth(), function (req, res, next) {
  res.render('profile', {
    userProfile: JSON.stringify(req.oidc.user, null, 2),
    title: 'Profile page',
    headline: process.env.APP_NAME,
    backgroundColor: process.env.BACKGROUND_COLOR,
    baseURL: process.env.BASE_URL,
  });
});

module.exports = router;

middlewares/validateLogoutToken.js

// このミドルウェアは、以下で定義されているログアウトトークンを検証します:
// https://openid.net/specs/openid-connect-backchannel-1_0.html#Validation

const jose = require('jose');

async function requiresValidLogoutToken(req, res, next) {

  // トークン検証用のリモートキーセットを取得する
  const JWKS = jose.createRemoteJWKSet(
    new URL(process.env.ISSUER_BASE_URL + '/.well-known/jwks.json')
  );

  const logoutToken = req.body.logout_token;

  if (!logoutToken) {
    res.status(400).send('Need logout token');
  }

  try {
    const { payload, protectedHeader } = await jose.jwtVerify(
      logoutToken,
      JWKS,
      {
        issuer: process.env.ISSUER_BASE_URL + '/',
        audience: process.env.CLIENT_ID,
        typ: 'JWT',
        maxTokenAge: '2 minutes',
      }
    );

    // ログアウトトークンに sub クレーム、sid クレーム、またはその両方が含まれていることを確認する
    if (!payload.sub && !payload.sid) {
      res
        .status(400)
        .send(
          'Error: Logout token must contain either sub claim or sid claim, or both'
        );
    }

    // ログアウトトークンに events クレームが含まれていることを確認する
    // その値は、メンバー名 http://schemas.openid.net/event/backchannel-logout を含む JSON オブジェクトであること
    if (!payload.events['http://schemas.openid.net/event/backchannel-logout']) {
      res
        .status(400)
        .send(
          'Error: Logout token must contain events claim with correct schema'
        );
    }

    // ログアウトトークンに nonce クレームが含まれていないことを確認する
    if (payload.nonce) {
      res
        .status(400)
        .send('Error: Logout token must not contain a nonce claim');
    }

    // 有効なログアウトトークンをリクエストオブジェクトに付加する
    req.logoutToken = payload;

    // トークンは有効、次のミドルウェアを呼び出す
    next();
  } catch (error) {
    res.status(400).send(`Error:  ${error.message}`);
  }
}

module.exports = requiresValidLogoutToken;

​

ログアウトトークンストア

トークン保存の一般的な方法として、セッションストアモデルの代わりにログアウトストアを定義する方法があります。アプリケーションは、永続化層に ログアウトトークン のコレクションを保持します。

アプリケーションが認証状態を確認する必要があるたびに、ログアウトトークンストアを照会して、セッションがまだ有効かどうかを確認します。ログアウトストアは、必要な情報だけを残すために、古い情報を定期的に削除します。

​

セキュリティに関する考慮事項

Back-Channel Logout Tokens はインターネット経由で配信されるため、それらを受信するコールバックエンドポイントは、信頼性と安全性を確保するためにベストプラクティスに従う必要があります。以下の推奨事項は網羅的なものではないため、実際のデプロイや運用状況に応じて適宜判断する必要があります。以下の一覧では、Back-Channel Logout Tokens を処理するアプリを「アプリ」と呼びます。

• アプリは、後で Back-Channel Logout token を受信した際に参照できるよう、ユーザーの login 時に受信したセッション ID (sid claim) を保存できなければなりません。
• アプリは、受信した token を JWT 検証のベストプラクティス に従って検証しなければなりません。
• アプリは、信頼できるテナントによって発行された token のみを受け入れなければなりません。悪意のある第三者が他の Auth0 テナントによって発行された token を送信しようとする可能性があるため、そのような試みは拒否しなければなりません。
• アプリは、アプリが認識できる sid 値 (セッション ID) を含む token のみを受け入れなければなりません。無効なセッション ID (期限切れまたは未認識) を含む token は拒否しなければなりません。
• アプリは、コールバックエンドポイントを TLS 経由でのみ公開しなければなりません。暗号化されていない通信チャネルは許可されません。
• アプリは、公開されている 送信元 IP アドレス の一覧からの request のみを受け入れることが推奨されます。
• アプリは、監視、ログ、およびレート制限に関する一般的なベストプラクティスに従うことが推奨されます。ただし、これらの詳細はこのドキュメントの範囲外です。
• アプリは、古くなったセッションや期限切れのセッションを定期的に削除することが推奨されます。
• endpoint アドレスに変更がある場合は、ログアウトトークンs が常に正しい Back-Channel Logout Callback URL に配信されるよう、テナントの設定と同期しなければなりません。