ineritとブログを同じKeycloakに接続すれば、ログインも自然に連携すると考えがちだ。しかし、認証サーバーを共有することと、各サービスがログイン状態を確立することは別の問題だった。
2026年11月の作業当時、片方のサービスでログインしても他方のサービスでは認証が引き継がれず、再認証が必要だった。その後、双方向のログイン連携、サービス別の権限、明示的ログアウト後の即座の再ログイン防止、既存アカウントの移行などに対応した。この記事は、当時の作業記録から得られた設計上の教訓である。現在の運用状況を改めて検証した結果ではない。
中央認証とサービスセッションは別物
ユーザーが認証サーバーにログインしていても、新たに訪れたサービスはまだその結果を確認していない可能性がある。サービスは認証状態を確認し、必要な検証を経て独自にログイン状態を構築しなければならない。これは、他のサービスのクッキーをそのまま読み込むこととは異なる。
障害を調査する際にも、質問を分解する必要がある。
- 認証サーバーに有効なSSOセッションが存在するか？
- 新しいサービスが認証確認を開始したか？
- 応答の検証と既存アカウントへの紐付けは成功したか？
- サービスが許可するユーザーと権限が一致しているか？
KeycloakはSSOユーザーセッションとクライアントセッションを区別しており、アプリケーション自体のセッションも別途存在しうる。有効期限ポリシーをひとまとまりとして捉えると、どの境界で状態が途切れたのかを把握しにくくなる。Keycloakセッション有効期限の設定
自動ログインと強制ログインは異なる
公開ページを開くたびに認証画面へリダイレクトするのか、既存の認証がある場合にのみログイン状態を引き継ぐのかは、異なるポリシーである。
例えば、Keycloak JavaScriptアダプターのlogin-requiredとcheck-ssoは、それぞれ異なるログイン体験を提供する。これは違いを説明するための例であり、当時ineritで該当オプションを使用していたという意味ではない。OpenID Connectのprompt=noneも、ユーザーとのインタラクションなしで処理するよう要求するだけであり、認証や同意を省略してくれるわけではない。必要に応じてlogin_requiredのような結果が返される。これを無条件に再試行すると、認証サーバーとサービスの間を往復し続ける可能性がある。Keycloak JavaScriptアダプター, OpenID Connect認証リクエスト
iframeベースのサイレントな認証確認は、ブラウザのサードパーティークッキー制限の影響も受ける。あるブラウザで成功したとしても、すべての環境で同じ動作を保証できるわけではない。
認証と利用承認は別概念
中央認証はユーザーの身元を確認するが、特定サービスの利用を許可するかどうかまでは自動的に決定しない。あるサービスで承認されたアカウントでも、他のサービスの利用条件は異なる可能性がある。この場合、パスワードを再入力させるよりも、承認待ち状態やアクセス制限状態を明確に区別して通知する方が望ましい。
権限はKeycloakのクライアントロールで表現するか、サービス側で独自に管理することもできる。どちらを選択しても、画面表示だけでなく、保護されたリクエストを処理する箇所でも検証を行わなければならない。プロトコル上のユーザー同意と、サービス運営上における利用承認は異なる概念である。Keycloakクライアントロール
ログアウトはユーザーの意図を含む
サービスセッションを削除しても、中央SSOセッションは残っている場合がある。このとき、ページがすぐに自動ログインを再開すると、ユーザーはログアウトボタンを押した直後に、ログイン済みの画面を目にすることになる。
まずは、現在のサービスのみからログアウトするのか、中央セッションも終了するのかを決定しなければならない。サービス単位のログアウトの場合、自動ログインの抑制状態をいつまで維持するのか、明示的なログインリクエストによってどう解除するのかも決める必要がある。この状態はユーザー体験のためにあり、サーバー側での認証・認可チェックを代替するものではない。
中央ログアウトにおいても、他のサービスのセッションや画面が即座に整理されると仮定してはならない。OpenID Connectには、認証サーバーに終了を要求するRP-Initiated Logoutと、サーバー間通知を扱うBack-Channel Logoutが別途定義されている。実際の適用方法は、サービスの要件と実装に応じて確認する必要がある。
アカウント移行と検証
既存アカウントの移行では、単にログインできるかどうかが確認すれば済むわけではない。データ所有権やサービス別の承認状態が正しいアカウントに紐付いているか、不明確または重複したアカウントはないかを確認する必要がある。OpenID Connectにおいて識別子の安定性を扱う基準は、issとsubの組み合わせである。ただし、この識別子があるからといって、既存のローカルアカウントとの紐付けが自動的に証明されるわけではない。OpenID Connectの識別子
検証時には、一度のログイン成功よりも、状態遷移を追跡することが重要である。
- どのサービスから開始しても、他のサービスへ移動する際に意図した認証フローが動作しているか？
- 未認証のユーザーが、公開画面でログインの無限ループに陥っていないか？
- 認証はされたが利用承認がない場合、適切な案内が表示されているか？
- 明示的ログアウト後、リフレッシュや再訪問でも意図したポリシーが維持されているか？
- 中央セッションとサービスセッションの有効期限が異なる場合、復旧可能であるか？
- 既存アカウントのデータと権限が正しく保持されているか？
SSOの核心は、ログイン画面を一度減らすことで終わらない。認証サーバーが証明した身元と、各サービスのセッション、権限、ユーザーのログアウト意図を、それぞれどこで管理するかを決める必要がある。
