一本の石造りの通路に、二つの扉が前後に続いている。

プロダクトノート

ログアウトの連鎖

ユーザーがログインするのは一度きりです。でも、その裏で作られる「鍵」は一本ではありません。ログアウトするときは、どの鍵を回収し、どこまでログイン状態を終了するのかを考える必要があります。

ログインは一度。でも鍵は三本できる

自社サービスに「Googleでログイン」を付けたとします。ユーザーが押すのは一つのボタンだけです。 その裏で、ログインの通り道にあるシステムはそれぞれ自分の鍵（セッション）を発行して保管します。

Googleが一本、Authrimが一本、自社アプリが一本。合わせて三本です。 どこかにセッションが残れば、操作を続けられたり、パスワードを入れずに入り直せたりすることがあります。

ログアウトとは、画面に「ログアウトしました」と出すことではなく、
終了させたい範囲を決め、その範囲のセッションを終了させることです。

トークンの失効は、別の話です

ここで「鍵」と呼んでいるのはセッションです。アクセストークンやリフレッシュトークンとは違います。 セッションを終了しても、発行ずみのトークンが自動的に失効するとは限りません。 トークンを止めるには、失効（revocation）という別の操作が必要です。

OIDCでは、セッションのログアウト、トークンの失効、上流IdPでのアカウント無効化を別の操作として扱います。 この記事で扱うのはセッションです。トークンがいつ効かなくなるかは、 トークンのイントロスペクションと失効で扱っています。

Authrim は「中間」に立っている

この連携には、上流のIdP、Authrim、自社アプリが登場します。 真ん中にいるAuthrimの役割は、相手によって変わります。

上流IdPは、自社サービスから見て「ログインさせる側」。自社アプリは「ログインを頼む側」。 Authrimは、上を向くか下を向くかで立場が入れ替わります。

上流IdP Google・Entra ID・Apple など Authrim 自社のIDサービス 自社アプリ / SaaS ユーザーが実際に使う画面 ログインを頼む ＝ お客の立場（RP） ログインさせる ＝ 受付の立場（OP） 上下で立場が 逆になる
旅行代理店に似ています。旅行者から見れば旅を手配する側、航空会社から見れば座席を買いに来る客です。 Authrimも、受付とお客の両方の立場にいます。ここでいう「中間」は、そういう意味です。

ログアウトは、たいてい途中で止まる

ログインは上から下へ流れます。一方、ログアウトは誰かが伝えない限り、次へ伝わりません。

上流IdPのセッションを終了しても、Authrimや自社アプリのセッションが自動的に消えるとは限りません。 下流へ終了を伝え、受け取った側も対象のセッションを終了する必要があります。次の図は、必要な通知方式と設定が揃った場合の連鎖です。

連鎖が切れている場合 上流IdP セッション終了ずみ 通知が届かない Authrim 鍵がまだ生きている 自社アプリ 鍵がまだ生きている 結果 ── ユーザーはまだ入れる 連鎖がつながっている場合 上流IdP セッション終了ずみ 「この人を切って」 署名つきの通知 Authrim 受け取って回収 ／ 下流へ中継 「この人を切って」 署名つきの通知 自社アプリ 受け取って回収 結果 ── 三本とも回収された
左右の違いは真ん中の矢印です。Authrimが通知を受け取り、下流へ送り直せるか。 さらに、上流IdPと各アプリの対応・設定も揃って、初めて連鎖が成立します。

現場では、こう見える

「鍵が残る」と言われても、すぐには想像しにくいかもしれません。問い合わせや監査では、次のような形で表れます。

場面 連鎖がないと起きること
退職・アカウント停止 人事側で権限を止めたのに、当人のPCではアプリが開いたままで、翌朝まで社内データが見えていた。
共有端末 店舗・病院・コールセンターで、前の担当者がログアウトしたはずなのに、別タブを開いたら前の人の画面が出た。
端末の紛失・盗難 「全デバイスからログアウト」を押したのに、実際には手元の端末のセッションしか切れていなかった。
インシデント対応 不正アクセスを検知して該当ユーザーを止めたが、攻撃者のセッションだけは有効期限まで生き続けた。
監査・審査 「ログアウトが全システムに伝わることを示してください」と言われ、示す材料がない。

どの例にもログアウトのボタンはあります。押せば画面も切り替わります。 ただ、実際にログアウトが効く範囲は、思っているより狭い。それが厄介なところです。

昔の伝え方が、使えなくなってきている

下流に伝える方法は大きく二つあります。そのうちブラウザを通す方法は、以前ほど頼れなくなっています。

ブラウザ経由でお願いする Authrim ブラウザ 見えない小窓を並べて通知 自社アプリ ブラウザのプライバシー保護で遮断されることがある。ユーザーがタブを閉じていたら届かない。 サーバー同士で直接伝える Authrim 署名つきの通知を直接送る ブラウザを一切経由しない 自社アプリ
上の方式は、ブラウザに「見えない小窓」を並べ、各アプリに通知します。 Safari・Firefox・Chromeのプライバシー強化で、この小窓は遮断される方向に進んでいます。 下の方式（バックチャネル）はサーバー同士で直接通信するため、ブラウザの状態に左右されません。 それでも必ず届くわけではありません。ネットワーク障害や受信側アプリの停止、タイムアウト、5xx応答では届きません。 再送やキュー、失敗の記録は実装側で用意する必要があります。

Authrimが対応しているのは、下の方式を受け取る側の能力です。 受け取る処理と、下流アプリへ送る処理は、別々に確かめる必要があります。

受け取る側と、配る側を確かめる

Authrimは、上流IdPに対してはログインを頼む側（RP）、アプリに対してはログインを提供する側（OP）です。ログアウトを中継するにも、両方の立場で仕様に沿って動く必要があります。

  • RP側：上流から届いたログアウト通知を検証し、対象となるAuthrimのセッションを終了する。
  • OP側：連携先アプリへログアウト通知を送り、アプリ側で対象セッションを終了できるようにする。

その二つの役割を確認する材料が、OPとRPそれぞれのログアウトプロファイル認定です。Authrimは、OpenID Foundationの公式適合性テストを使うセルフ認定手続きを経て、両側の認定を取得しています。

認定が示すのは、対象バージョンの実装が、申請したプロファイルの適合性テストを通過したことです。お客様の接続先やネットワークまで含め、すべてのセッションがすぐに終了するという保証ではありません。

実際に連鎖をつなぐには、上流IdPと各アプリが必要な方式に対応し、通知先と対象セッションの対応付けが設定されている必要があります。上流でアカウントを止めても、必ずログアウト通知が出るとは限りません。通知が届かなかったときの再送や失敗の確認も含め、利用する構成で確かめます。

認定の対象とバージョンは、OpenID Foundationの Certified OpenID Relying Parties & Logout Profiles と 認定制度の説明 から確認できます。

ログアウトしたあと、どこにログイン状態が残るのか。

共有端末を次の人へ渡すときも、退職者のアクセスを止めるときも、知りたいのはそこです。Authrimは通知を受け取る側と配る側を担い、上流IdPとアプリの間でセッション終了をつなぎます。認定は実装を確認する材料になります。そのうえで、接続先も含めて意図した範囲のセッションが終了するか、利用する構成で確かめます。