OAuth2 の client_credentials グラント（クライアントアプリケーション自身がトークンを取得するフロー）を、ユーザー認証に流用したシステムが実在した。メールアドレスを client_id、BCrypt ハッシュ化したパスワードを client_secret として扱い、Spring Authorization Server 約380行の設定でトークンを発行し続けたという事例が dev.to で公開されている。このアーキテクチャの何が問題で、どう移行されたのか——SRE・インフラ視点で読み解いていく。
自前認証基盤が「負債」になる構造的理由
アクセストークンの有効期限は24時間、リフレッシュトークンは48時間。発行済みトークンは oauth2_authorization テーブルに格納され、起動時ジョブで古い行を削除していた。他のサービスはトークンを自分でパースせず、毎回 auth サービスへのイントロスペクション（トークンの正当性を問い合わせる仕組み）コールで検証していた。
この設計が持つオブザーバビリティ上のリスクは明確だ。認証サービスはすべての認証済みリクエストのホットパス（処理の中心経路）に位置し、Single Point of Failure になっている。SLO（サービスレベル目標）を設定する際、認証サービスの可用性がそのまま全サービスの可用性上限を規定する。エラーバジェット（許容できる障害の余裕）を消費する要因として、データベースの行削除ジョブの遅延やロックが波及するリスクも無視できない。
記事の著者が指摘するとおり、自前認証の失敗モードは劇的な侵害ではない。「誰も所有者として手を挙げていない、重要なインフラになってしまう」という状態こそが典型的な末路だ。コンプライアンス要件・エンタープライズ顧客からの IdP（Identity Provider、外部の認証基盤）連携要求・維持コストの三つが重なって、初めて移行が動き出した。
Google Identity Platform への移行と検証方式の分離
インフラがすでに Google Cloud 上にあるため、移行先は Google Identity Platform（Firebase Authentication を包含するエンタープライズ向け認証基盤）を選択した。これにより IdP が「別サービスとの統合」ではなく「インフラのネイティブコンポーネント」になる。IaC（Infrastructure as Code）の観点では、Terraform の google_identity_platform_tenant リソースで環境ごとのテナントを管理できる構成になる。
トークン検証の方式は二層に分かれた。認証サービス自身は Firebase Admin SDK をサーブレットフィルターで呼び出して ID トークンを検証する。その他のサービスは、プロバイダーの JWKS（JSON Web Key Set、公開鍵の配布エンドポイント）を向いた Spring Resource Server の標準設定で検証する。後者は「コードではなく設定」で完結するため、以後の維持コストが大幅に下がる。
カスタムクレーム（トークンに埋め込む追加属性）として、選択中の組織 ID・ユーザーの内部識別子・サービスアカウントかどうかのフラグを付与している。これはオブザーバビリティの観点でも重要で、ログやトレースにトークンのカスタムクレームを伝播させることで、分散トレーシングのコンテキストとしてリクエスト単位の認可状態を追跡しやすくなる。
「デュアル認証なし・一発切り替え」という判断とその代償
移行で最も議論を呼ぶ設計判断が、デュアル認証期間を設けなかった点だ。バックエンド5リポジトリとフロントエンドを同一日にマージし、旧トークンと新トークンを並走させる互換レイヤーを一切作らなかった。
一般に段階移行（Feature Flag でトラフィックの一部を新認証へルーティングするなど）は安全に見える。しかし認証面を二重に維持することで、テスト対象の組み合わせが倍増し、互換レイヤーが「6ヶ月後も残っているもの」になるリスクがある。制御下にある単一チーム・固定クライアントという前提があれば、一発切り替えと全員待機による集中対応のほうがリスクが低いという判断は、SRE 的な観点でも理解できる。
実際のコストは移行直後の1週間に集中した。設定ミスの修正・テストフィクスチャの修復・実トラフィックで初めて露出した問題への対応がそれにあたる。カオスエンジニアリングで事前に障害を注入するアプローチとは逆に、「痛みを一つの観測ウィンドウに集める」という戦略だ。
SRE が移行計画を立てる際に整理しておきたいポイントを以下にまとめる。
- 認証サービスが SPOF になっていないか確認し、移行前後の SLO 目標を明示的に設定する
- JWKS 検証への切り替えによりイントロスペクションコールが消えることで、認証サービスへのトラフィック集中が緩和される
- カスタムクレームをログ・トレースに伝播させ、障害時に認可コンテキストを追跡できるようにする
- デュアル認証期間を設ける場合は、廃止タイムラインを事前に決め、IaC でその期限をコード化して管理する
パスワードハッシュを「誰もメンテしたくない列」として持ち続けるコストは、可視化されにくい。認証基盤を外部 IdP に委譲することの本質は、セキュリティの向上だけでなく、オンコール対象から認証ロジックを外すことにある。