『認証が落ちる＝サービス全停止』は設計の問題
SaaSのインシデント事例で、認証基盤（自社IdP・Auth0・Cognito・Keycloak等）の障害が引き金で全体停止するケースが少なくありません。認証はクリティカルパス上にあり、ここで止まると新規ログイン・既存セッション継続・APIアクセスすべてが停止します。本記事では認証停止時にも『一定の縮退運転』でサービスを継続させる設計パターンを、編集部の取材ベースで整理します。
採用すべき5つのシグナル
- BtoB SaaSで認証基盤のSLAが事業のSLAの上限になっている
- 認証SaaSの過去障害で全停止を経験した
- マルチリージョン展開で認証だけが単一リージョン依存
- 規制業界（金融・医療）でダウンタイムが許されない
- 長時間セッションを必要とするB2B業務
縮退運転の3レイヤ
レイヤ1: セッション継続: 既存セッションは認証基盤に問い合わせず継続。JWTの署名検証はローカル公開鍵で完結。
レイヤ2: 段階的機能制限: 新規ログイン・パスワード変更・MFA等のクリティカルでない操作を一時的にメンテ表示。読み取り中心の機能は継続。
レイヤ3: フェイルオーバ: セカンダリ認証基盤への自動切り替え（事前同期されたDB＋セカンダリIdP）。
実装パターン
- JWT検証のキャッシュ化: 認証基盤公開鍵を24時間キャッシュ・障害時もローカル検証可能
- セッショントークンの長期化: アクセストークン15分・リフレッシュトークン7日のように分離
- Read-only モード: 認証基盤未応答時に書き込み系APIを一時無効化・読み取りは継続
- キャッシュ層への退避: ユーザー情報・権限情報をRedis等にキャッシュし障害時参照
- ヘルスチェックエンドポイント: 認証基盤の状態を別パスで監視・自動切替トリガに
主要IdPでの落とし穴
- Auth0: 過去2024年・2025年に複数の地域別障害。マルチテナント設計でテナント単位の影響範囲を制御
- Cognito: AWSリージョン障害でユーザー認証が広域影響。フェイルオーバ設計が複雑
- Okta: エンタープライズ実績豊富だが2022年の大規模インシデントあり
- Keycloak（Self-host）: 自分で障害復旧する負荷あり・運用負荷高
- Supabase Auth: PostgreSQL依存・DB障害＝認証障害
テストの実装
- Chaos Engineering: 認証基盤への接続を意図的にブロックして縮退動作を検証
- Game Days: 月1回・認証障害シミュレーションを運用チームで実施
- SLO設計: 認証基盤のダウンタイムを許容するSLO目標に
- Postmortem: 認証関連インシデントは必ず根本原因分析
失敗パターン
- 毎回認証基盤に問い合わせ: キャッシュ層なし・障害時即停止
- 長すぎるトークン: 30日トークン等は別のセキュリティ問題を招く
- フェイルオーバ未テスト: 設計はあるが切替したことがない
- 認証基盤の一極集中: 全機能で同じIdPに依存・障害影響範囲が大きい
30日実装プラン
- 1週目: 現状の認証基盤依存マップ作成
- 2週目: JWT検証ローカル化・公開鍵キャッシュ
- 3週目: Read-onlyモード・段階的縮退設計
- 4週目: 障害シミュレーション・Game Day運用
関連リンク
認証ライブラリ選定は Better-Auth深掘り、OAuth/OIDC実装は OAuth/OIDC実践、可観測性は Observability実践 を参照してください。SRE全般は SREのキャリア もどうぞ。