🎯 はじめに：認証基盤の選定は「機能の有無」だけでは決まらない
本記事はシリーズ 「BtoB SaaS セキュリティ設計」の第 2 回 です。第 1 回 BtoB マルチテナント SaaS のセキュリティ設計総覧 で総論を扱いましたが、本記事では認証層の中核である 「なぜ AWS Cognito を選んだのか」 に焦点を当てます。
認証基盤の比較記事は世に多くありますが、本記事の特徴は次の 2 点です。
- 「採用しなかった選択肢」の理由を公式ドキュメントで裏付ける：Google Cloud Identity Platform（GCIP）/ Firebase Authentication について、公式ドキュメントを直接確認して何が無いのかを確かめる
- コストと脅威モデルのトレードオフを開示する：Cognito Plus tier を採用しなかった判断基準を、抽象論ではなく当社の運用条件に基づいて説明する
🔐 結論：何を選んで、何を避けたか
| 採用した | 避けた |
|---|---|
| AWS Cognito User Pool（Essentials tier） | Google Cloud Identity Platform / Firebase Authentication |
| パスキー（WebAuthn / FIDO2）ネイティブ機能 | 第三者拡張に依存するパスキー実装 |
| OIDC Authorization Code Flow + PKCE | client_secret 依存のフロー |
| パスワード認証との 併用フォールバック | パスキー強制移行（デバイス紛失リスク） |
| Cognito Essentials tier | Plus tier（Adaptive Authentication / IP リスク評価） |
選定理由は 「OIDC with PKCE と WebAuthn の両方をネイティブに備える」「BtoB 管理者ログインに見合う料金体系」 に集約されます。
🛡️ なぜ「重ねる」のか — state / nonce / PKCE / WebAuthn の独立した役割
認証層の議論で混同されがちな 4 つの仕組みを整理します。これらは 互いに置き換え可能ではなく、それぞれ別の攻撃ベクトルに対応する独立した防御 です。
| 仕組み | 防ぐ攻撃 | 必要なクライアント |
|---|---|---|
| state | CSRF（リクエスト改ざん・横取り） | すべて |
| nonce | ID トークンのリプレイ（再送信攻撃） | OIDC を使うすべて |
| PKCE | 認可コードの横取り（Authorization Code Interception Attack） | client_secret を秘密にできない SPA・モバイル必須 |
| WebAuthn / パスキー | フィッシング全般（パスワード詐取・MITM） | パスワードレスを目指すすべて |
state は「行きの守り」、nonce は「帰りの守り」、PKCE は「中間者の守り」、WebAuthn は「人間そのものの守り」。
現代の OIDC 実装ベストプラクティスは 4 つすべてを併用 することです。1 つでも欠けると、その層に対する攻撃が成立してしまいます。
🆚 論点 A：GCIP / Firebase Authentication に「OIDC with PKCE」が無い
第 1 回で軽く触れましたが、ここで公式ドキュメントを直接確認した結果を提示します。
PKCE が SPA・モバイルで必須な理由
OAuth 2.0 の標準的な認可コードフローは、認可コード → アクセストークンの交換時に client_secret を提示してクライアントを認証します。しかし SPA・モバイルアプリではコードがクライアント側に展開されるため、 secret を秘密にできません 。
ここに 認可コード横取り攻撃（Authorization Code Interception Attack） が成立する隙が生まれます。攻撃者が何らかの方法でリダイレクト経由の認可コードを横取りできれば、client_secret は不要なのでトークンに交換できてしまう。
PKCE はこれを 「リクエストごとに動的に生成する code_verifier / code_challenge ペア」 で防ぎます。code_verifier を知らない攻撃者は、認可コードを盗んでもトークンに交換できません。 OAuth 2.1 ドラフトでは全クライアントで PKCE 必須 とされており、現代の事実上の必須要件です。
公式ドキュメント上で確認できる事実
| 観点 | 公式ドキュメントの記載 |
|---|---|
| GCIP / Firebase Auth は OIDC OP（IdP）として機能するか | RP（Relying Party）としてのみ。自身を OP として SPA に提供する仕様は文書化されていない |
.well-known/openid-configuration discovery エンドポイントの公開 | 記載なし |
| PKCE / code_verifier / code_challenge の言及 | 自身を OP として使う文脈で 一切記載なし |
つまり GCIP / Firebase Auth は 「外部 OIDC IdP を消費する RP」 として設計されており、 「SPA・モバイルから OIDC + PKCE で直接認証する OP」としては機能しません 。Firebase Authentication の認証は独自 SDK + REST API 経由で完結しており、ブラウザリダイレクトを伴う標準 OIDC フローを前提にしていない設計です。
これは Google サポートへの問い合わせでも同様の回答を得ています。
Cognito との対比
AWS Cognito User Pool は Hosted UI / Managed Login を介して OIDC OP として PKCE 認可コードフローをネイティブ提供 します。SPA・モバイルから標準 OIDC で認証でき、/.well-known/openid-configuration discovery エンドポイントも公開されます。これが BtoB SaaS で「標準プロトコルに乗る」ための基礎条件を満たします。
🆚 論点 B：GCIP / Firebase Authentication にパスキーがネイティブで無い
論点 A とは独立した第 2 の弱点として、 WebAuthn / パスキーのネイティブ対応の欠如 があります。
| 観点 | AWS Cognito | Firebase Auth / GCIP |
|---|---|---|
| パスキー / WebAuthn | 2025 年から Lite tier 以外で ネイティブ対応 | 第三者拡張（firebase-web-authn）依存 |
| GitHub feature request | — | #2123（2019 年〜）が未解決のまま放置 |
| 公式 SDK の WebAuthn 対応 | aws-amplify/auth で signIn({ preferredChallenge: 'WEB_AUTHN' }) | 公式対応なし |
第三者拡張に依存することのリスクは次の 3 点です。
- メンテナンスの不確実性 : 拡張のメンテナーが活動停止すれば自社で引き取らざるを得ない
- 公式サポートの欠如 : Firebase の有償サポート対象外
- 将来の互換性 : Firebase 本体の更新で拡張が動作しなくなるリスク
BtoB SaaS で 管理者ログインの最強防御をパスキーで構築する戦略 を取る以上、第三者拡張依存は受け入れ難い選択肢でした。
🤔 なぜ Google は OIDC with PKCE とパスキーを提供しないのか（推測）
公式に Google が表明した文書はありませんが、状況証拠から導ける合理的な仮説は次の 5 つです。
① Firebase Auth はもともと「OIDC OP」として設計されていない
Firebase Auth の中核は 2016 年に Firebase に統合された Identity Toolkit API で、これは独自 SDK 専用の REST API + Firebase ID Token で完結する設計です。 PKCE を導入する「土俵」が無い 。
② Google 内での役割分担：OIDC OP は accounts.google.com の責務
Google には Google Identity Services（accounts.google.com） が既に OIDC OP として PKCE 含めて存在します。Firebase Auth / GCIP は 「アプリ独自のユーザー DB を持つための B2C CIAM」 であり、両者を統合する戦略が取られなかった。
③ ビジネス戦略：「OIDC OP が必要なら Auth0 / Okta を使え」
GCP のドキュメントとパートナー戦略は、 本格的な IdP 機能はサードパーティ連携に委ねる 形に寄っています。Auth0（Okta）等で十分という想定です。
④ Firebase 独自の認証フローと OIDC OP は両立しづらい
カスタムトークン認証・匿名認証・電話番号認証など、 OIDC 標準にない独自フロー が主要機能として存在します。これらと OIDC OP を同居させるとプロトコル適合の検証コストが膨大です。
⑤ GCIP への投資が長らく停滞している
WebAuthn / パスキーの GitHub feature request が 2019 年から未解決のまま放置されている事実は、 Google 社内での優先度の低さ を示唆します。Cognito が 2025 年にネイティブパスキー対応を入れたのとは対照的な動きです。
「できないのではなく、やる動機が組織的に無い」 という構造的な問題と捉えるのが、状況に最も整合する説明です。
💡 「Essentials tier + パスキー」が成立する当社の条件
最後に、Cognito Plus tier（Adaptive Authentication / IP リスク評価）を採用しなかった判断について、コストと脅威モデルの観点から開示します。
Plus tier の特徴：
- 侵害クレデンシャル検知 : 既知の漏洩パスワード DB と照合
- Adaptive Authentication : サインインのリスク（IP・デバイス・行動）を評価して MFA を動的要求
- 追加課金 : 月間アクティブユーザー単位（$0.05/MAU 程度）
当社の運用条件：
- セルフサインアップ無効 : 全アカウントが管理者経由でのプロビジョニング
- 管理者ログインに限定 : エンドユーザー向けのログインは別系統（脅威モデルが大きく異なる）
- アカウント数が限定的 : 大量ブルートフォース攻撃の対象になりにくい
脅威ベクトルが「セルフサインアップで増えるアカウントの侵害」ではなく、「特権アカウントへのフィッシング」に集中している ため、Adaptive Authentication よりも パスキー（フィッシング耐性） がコスト対効果で優位という判断です。
ビジネスが拡大して脅威モデルが変化したら、Plus tier への切り替えは構成変更で対応できます。 「今の脅威モデルに合った最小構成」 を選ぶことが、過剰投資を避ける現実的なアプローチでした。
🧭 まとめ
- AWS Cognito User Pool（Essentials tier）+ パスキー が、 OIDC with PKCE / WebAuthn の両方をネイティブに備える 唯一の現実的な選択肢
- GCIP / Firebase Auth は構造的に OIDC OP ではなく、PKCE もパスキーもネイティブ対応していない（公式ドキュメントで裏付け済）
- 4 つの防御（state / nonce / PKCE / WebAuthn）は 独立した攻撃ベクトル に対応するので併用が必須
- Plus tier は 脅威モデルとコスト のトレードオフで現時点では不要と判断
認証基盤は 「機能の網羅性」よりも「自社の脅威モデルにフィットする最小構成」 で選ぶべきで、本記事の判断軸が読者の選定の参考になれば幸いです。
📚 シリーズ記事
| # | タイトル | 内容 |
|---|---|---|
| 1 | 総覧 | 認証・認可・通信・インフラ・監査の多層防御の全体像 |
| 2 | AWS Cognito + パスキーを選んだ理由 （本記事） | GCIP に OIDC with PKCE とパスキーが無い問題と採用判断 |
| 3 | OAuth / OIDC / SAML / WebAuthn の歴史 | 認証プロトコルの系譜と各仕様の役割 |
| 4 | 3 層認可防御の実装パターン (公開予定) | Defense in Depth の実装と DB SSOT 方式 |
| 5 | WIF でキーレス認証 (公開予定) | 静的鍵を使わない CI / クラウド連携の実践 |
| 6 | Web レピュテーション / IP レピュテーション (公開予定) | Cognito Plus tier 等の脅威保護機能 |
| 7 | ログインセキュリティのベストプラクティス (公開予定) | パスワードポリシー、MFA、セッション管理 |
| 8 | 開発環境のセキュリティ対策 (公開予定) | DevContainer / SAST / Secret Scanning |
| 9 | ゼロトラストアーキテクチャ | 境界はネットワークから ID へ、IPv6 と SaaS が変えた前提 |
| 10 | IPA セキュリティアクションへの対応 (公開予定) | 中小企業向け実装ガイド |
📖 関連用語
- パスキー — フィッシング耐性が極めて高いパスワードレス認証
- WebAuthn — W3C 標準の Web 認証 API、パスキーの基盤
- PKCE — OAuth 2.0 で認可コードの横取りを防ぐ拡張仕様
- AWS Cognito — マネージド認証・認可サービス
- 多層防御 — 独立した複数の層で重ねて防御する設計思想