認証認可アーキテクチャの変遷（4）認可サーバーの内部構造と信頼性設計

本シリーズは5部構成である。

• 第1部: モノリスから認証基盤へ
• 第2部: API Gatewayとマイクロサービス
• 第3部: クライアント認証の高度化と段階的移行
• 第4部（本記事）: 認可サーバーの内部構造と信頼性設計
• 第5部: 自作認可サーバーのデータモデルと運用設計

第1〜3部は認可サーバー（AS）を「使う側」の視点で書いた。ASはひとつの箱として扱い、その周りにGatewayやサービスをどう配置するかを論じてきた。第4部では箱の中を開ける。ASそのものを選定・構築・運用する立場——認証基盤チーム、あるいはIDaaSの技術評価をする立場——から、ASの内部をどう構えるかにも設計の幅があり、それぞれ解決する課題が違うことを整理する。「どのサーバーが何の処理をすべきか」という本シリーズの問いの、最後のピースである。

認証サーバーと認可サーバーは分けるべきか

まずよくある疑問から。「認証（AuthN）と認可（AuthZ）は別物だと習ったのに、なぜKeycloakやAuth0はひとつのサーバーで両方やっているのか？　分けるべきではないのか？」

プロトコル上は一体が標準形

OIDCのOpenID Providerは、OAuth 2.0の認可サーバーの拡張として定義されている。つまり仕様の設計からして「トークンを発行するサーバーが、その前段の認証も司る」形が前提だ。IDトークンとアクセストークンを同一発行者（iss）が出すことでセッションの整合性が取りやすく、市販・OSS製品もほぼすべて一体型である。製品・デプロイの単位として分けないのが一般的、がまず答えになる。

しかし「関心」は明確に2つある

一体が標準とはいえ、ASの中身をよく見ると性質の異なる2つの関心が同居している。

変化速度の違うものが同居しているとき、境界を引きたくなるのはアーキテクチャの一般則だ。実際、内部構造としての分離パターンは確立している。

パターン1: ログイン/同意の外部化（Ory Hydraモデル）

ASをプロトコル処理とトークン発行に特化させ、「ユーザーが誰か」の判定は外部のコンポーネントに委譲する。OSSのOry Hydraが明示的にこの設計を採っているので、ここではHydraモデルと呼ぶ。

解決する課題：

• 認証手段の進化（パスキー対応、リスクベース認証の追加）をプロトコル実装のリリースから切り離せる。トークン発行系は「枯らして固める」、認証系は「速く回す」という別々の変更管理を適用できる
• ログイン画面のUX・ブランディングを製品の制約から解放できる。IdP導入で「ログイン画面のカスタマイズが基盤チームの優先度次第」になる問題（第1部）への構造的な回答でもある
• 認証強度（どの手段で認証したか）をacr/amrクレームとしてトークンに刻む起点が明確になる。「この操作は多要素認証済みのセッションでのみ許可」のようなステップアップ認証の土台になる

トレードオフ：

• AS⇔ログインアプリ間の受け渡し（challengeの検証、なりすまし防止）という新しい攻撃面を自分で設計することになる
• ログアウト整合性の関与者が増える。第1部で「IdPとアプリのセッション二重管理」を挙げたが、ここではIdPの内部にさらにセッション境界が増える
• 障害モードが増える。ログインアプリが落ちると新規認証だけ死に、トークン更新は生きる——という部分障害は、切り分けが明確になる利点と、運用が複雑になる欠点の両面がある

パターン2: フェデレーション分離（認証を上流に委譲）

ASが認証を自前で持たず、上流のIdPにOIDC/SAMLで委譲する（認証フェデレーション）。ASは「上流の認証結果を受けて、自ドメインのトークンを発行する」役に徹する。

これが効くのは認証の資産がすでに別の場所にあるケースだ。社内の既存認証基盤を活かしてAPI向けASだけ新設する、企業買収で複数のIdPが併存している、B2Bで顧客企業のIdPを受け入れる（エンタープライズSSO）——いずれも「認証はよそ、トークン発行はうち」という分業になる。第3部の段階的移行の文脈では、レガシー認証を生かしたままトークン発行だけ先に近代化する中間段階としても使える。

トレードオフは、認証強度やアカウント状態が上流依存になることだ。上流でMFAが解除されてもASは気づけないので、acrの伝搬や再認証要求（max_age）の設計が必要になる。信頼の連鎖は、繋いだ分だけ検証責任も連なる。

パターン3: 認可判断の境界 — ASに認可を吸い込まない

3つ目は分離というより境界の防衛の話だ。ASが担う「認可」は、スコープの発行と同意の管理という粗粒度までに留めるべきで、「このユーザーはこのリソースを操作できるか」という細粒度の判断をASに持ち込まない。

ASを運用していると、各サービスから「権限情報をトークンに入れてほしい」という要望が集まり、トークンが肥大化し、ASがドメイン知識の集積地になっていく引力が働く。これは第2部のパターンC（Gatewayに全認可を集約）と同型の失敗で、中央のコンポーネントは便利であるほどドメインロジックを吸い込む。トークンに載せるのは「安定した事実」（ユーザーID、テナント、組織上のロール）までとし、リソース単位の判断はRSまたはPDP（第2部）に置く、という規律を最初に決めておく価値がある。

で、どうすべきか

私の考えは「プロセスとしては一体で始め、モジュール境界だけ最初から引いておく」だ。認証モジュールとトークン発行モジュールのインターフェース（「誰が・いつ・どの強度で認証されたか」を渡す内部契約）を明示しておけば、後からHydraモデルへ分離する道は残る。最初からプロセス分離すると、上記のトレードオフ（受け渡し設計、ログアウト、障害モード）を課題が顕在化する前に全部払うことになる。分離そのものに価値があるのではなく、変更管理を分けたくなったときに分離できる構造に価値がある。

ASの信頼性設計

ASを運用する側にとって最大の非機能要件は可用性だ。第1部で「IdPは単一障害点化する」と書いたが、運用側から見るとこれは設計で緩和できる。

落ちても全部は死なない設計 — 状態の分類

ASの機能を「状態を持つか」で分類すると、障害時の生存性が変わる。

この表から設計指針が出る。「ASが30分落ちたとき、何が動き続けるべきか」を先に決め、そこから逆算してトークン形式と寿命を選ぶ。JWT+JWKSキャッシュなら「ログイン済みユーザーのAPI利用は継続、新規ログインだけ不可」という部分故障に落とせる。逆に全APIがイントロスペクションに依存する構成では、ASの可用性が文字通り全システムの可用性になる。第1部・第2部で論じたトークン形式のトレードオフは、可用性設計の言葉に翻訳するとこうなるわけだ。

鍵のライフサイクル

署名鍵はASの信頼の根であり、漏洩すれば攻撃者が任意のトークンを鋳造できる。設計すべきは2つ（鍵ローテーション）。

• ローテーションの手順: 「新鍵をJWKSに追加 → RS側のキャッシュが行き渡るのを待つ → 発行を新鍵に切替 → 旧鍵で発行したトークンが全て失効してからJWKSから撤去」。この順序を崩すと検証エラーの嵐になる。kid（Key ID）でトークンと鍵を対応付けるのはこの手順のためにある。緊急ローテーション（漏洩疑い時）は全トークン即失効とセットになるので、平時ローテーションとは別の手順として演習しておくべきだ
• 鍵の保管: 保証レベルの高いドメイン（金融、行政）では、秘密鍵をHSM/KMSに置いて署名操作だけを切り出し、ASプロセス自体は秘密鍵の平文に触れない構成まで踏み込む。「ASが侵害されても鍵は漏れない」が成立すると、インシデント時の最悪シナリオが「不正発行の停止」で済み、「全トークン基盤の信頼喪失」まで行かない

フルスクラッチするなら — 品質の外部物差し

第1部で「自作はほぼ推奨しない」と書いた。その原則は変わらないが、自作が正当化されるケースはある。認証基盤そのものが提供プロダクトである、既製品では満たせない業務要件・データ主権要件がある、などだ。その場合に重要なのは、「何を作れば安全か」を自分で発明しないことである。幸い、外部の物差しが揃っている。

• FAPI 2.0 Security Profile: 金融グレードのAPIのために策定されたOAuth/OIDCの絞り込みプロファイル。認可リクエストを事前にバックチャネルで登録するPAR（Pushed Authorization Requests, RFC 9126。認可リクエストの改竄・漏洩をフロントチャネルから排除する）、クライアント認証はprivate_key_jwtまたはmTLSのみ、フローは認可コード+PKCEのみ、mix-up攻撃対策のissレスポンスパラメータ——と、第3部までに登場した部品の「正解の組み合わせ」が仕様として固まっている。金融でなくても、セキュリティ設計の到達点のリファレンスとして読む価値がある
• OpenID Conformance Suite: OpenID Foundationが提供する適合性テストスイート。OIDC/FAPIの仕様準拠を機械的に検証でき、自作実装の回帰テストとして機能する。「仕様に準拠しているつもり」と「テストが通る」の距離は、認証プロトコルでは特に遠い
• JOSE/JWTライブラリは自作しない: フルスクラッチの範囲からも暗号処理は除外する。algの混同攻撃、署名検証のバイパスなど、JWT処理の脆弱性は歴史的に実装バグから生まれている。ここは実績あるライブラリに任せ、自作するのはその上のプロトコルオーケストレーションまでに留める

この3つを別の言い方でまとめると、フルスクラッチとは「仕様の解釈を自分で決めること」ではなく「確立された仕様群を、自分の要件に合わせて正確に組み立てること」である。創造性を発揮する場所はプロトコルではなく、その周辺——データモデル、運用性、既存システムとの統合——にある。

まとめ: 内部構造の選択肢と価値

第1〜3部で扱った「ASの外側」の変遷と同じで、内部構造にも万能解はなく、あるのは課題との対応関係だけだ。使う側にとっても、この内部構造の選択肢を知っておくことはIDaaS・OSS選定の評価軸になる——「この製品はログインフローをどこまで外部化できるか」「鍵管理はどの水準まで対応しているか」は、まさにここで論じた設計の自由度を問う質問である。