日本語
アイデンティティプロバイダの選び方：エンジニアリングチームの評価フレームワーク
実際のエンタープライズ要件から構築された実践的な IdP 評価フレームワーク。プロトコルの深さ、移行、マルチテナンシー、AI対応、そして多くのチェックリストが見落とす基準を網羅します。
Yijun
Developer
Developer
実際のエンタープライズ要件から構築された実践的な IdP 評価フレームワーク。プロトコルの深さ、移行、マルチテナンシー、AI対応、そして多くのチェックリストが見落とす基準を網羅します。
ほとんどのアイデンティティプロバイダの比較記事は、アイデンティティプロバイダ自身が執筆しています。驚きでしょう？自社製品が持つ機能だけをリストし、持っていない部分は飛ばして、「客観的ガイド」と称するのです。
これは、そうではありません。
私たちは実際のエンタープライズ評価依頼—調達チームがベンダーに送る実際のスプレッドシートやRFPドキュメント—を何十件もレビューしてきました。パターンは明らかで、エンジニアリングチームは本当に重要な基準を常に軽視し、重要でない基準を重視し過ぎています。
その結果？チームはデモに基づいて IdP を選び、6 ヶ月後には移行の難しさに気づき、再評価を始めることになります。
これは、私たちが本当は誰かから教えて欲しかった評価フレームワークです。B2B SaaS 企業のエンジニアリングチーム向け—社員向けのワークフォース SSO ではなく、実際にプロダクトを構築している人たちのためのものです。
斜め読みする方へ、要点だけ：
このガイドの残り部分では、各評価軸を詳細に解説し、質問すべきポイントや警戒点を紹介します。
以下の方におすすめ：
以下の方には対象外です：
市場にあるすべての IdP は「OAuth2 や OIDC をサポートします」と言うでしょう。それは大前提。本当に重要なのは、その深さです。
必須：
ますます重要になっているもの：
多くのチームが意識しない質問：この IdP を OIDC プロバイダーとして使えるか（消費者としてだけでなく）？
なぜ重要か：SaaS が成長すると、パートナーや顧客があなたのアイデンティティシステムで自分のツールへのログインを求めてくるかもしれません。トークンの発行、同意管理、サードパーティアプリ登録管理が必要です。外部 IdP しか利用できずプロバイダーにはなれないなら、外部連携で詰まります。
質問例：
トークンは IdP とサービス間の契約です。カスタマイズできなければ、下流サービスが追加 API コールをする必要があり、ユーザーの許可を逐次確認することになります。
質問例：
{"org_id": "org_123", "role": "admin", "auth_level": 2 } のようなトークンがあれば、API ミドルウェアでワンライナーで認可判断が可能です。{"sub": "user_456"} だけでは、都度 IdP や DB に確認が必要。大規模運用では、この差がリクエスト毎 2ms と 200ms の違いになります。
どの IdP もメール／パスワード・SNS ログインは対応しています。つまり、ここまでで全候補が残ります。
違いはデモでスルーされがちな細部です。
多くの評価はデモの段階で止まりますが、セッション・トークン管理は壊れた時に初めて本質的な問題が顕在化します— そして壊れるとユーザー全員が一斉ログアウトします。
地味ですが絶対に重要。
app.yourproduct.comとapi.yourproduct.com のように、複数サブドメインをまたいでセッション共有可能ですか？どうやるかも確認。ユーザーは数分ではなく数週間ログイン状態を求めています。しかし180日間の永続セッションと30分セッションではセキュリティも全く異なります。
質問例：
RBAC（ロールベースアクセス制御）は最低限。RBAC がないなら候補から除外ですが、B2B SaaS において RBAC だけでは不十分です。
ユーザーは組織に所属し、組織内での権限はプラットフォーム全体の権限と別に管理される必要があります。
同一ユーザーが Org A では管理者、Org B では閲覧者ということも。IdP がこれを素直に表現できなければ、アプリ側で独自権限システムを構築する羽目になり、二重管理です。
質問例：
金融・医療・高リスク操作のあるプロダクトでは、「認証済み」にもレベルがあります。
ダッシュボード閲覧だけならセッションクッキーで十分。送金など高リスク操作時は、追加の MFA（多要素認証）を要求したい。
これはステップアップ認証と呼ばれ、トークンシステムに**認証レベル（auth_level）**を一級市民として持つことが必要です。
質問例：
auth_level クレームが入り、バックエンドで確認できますか？auth_level の有効期限はセッション本体とは独立して管理できますか？IdP がネイティブに対応していなければ、自分達で作るしかありません— そしてそれはまさに IdP に頼りたかった部分そのものです。
理想は：API ミドルウェアがトークンを読み取り、ユーザーの org・role・auth_level から即座に認可判断できること。
現実は多くの IdP で：トークンからユーザー情報しか分からず、許可範囲を都度追加 API で確認しなければならない。
この追加確認コールは遅延や外部依存、失敗ケースを増やします。1秒間に 1,000 リクエストなら、認可のためのネットワークホップは避けるべきです。
誰も語りたがらない統計ですが、IdP 評価は「新 IdP の品質」より「既存ユーザーをどう移行するか」によって頓挫することが多いです。
10 万人以上のユーザーがいれば、移行は「Nice to have」ではなく「プロジェクト全体の成功要件」です。
1. 既存パスワードハッシュの一括インポート
既存システムで暗号化されたパスワード（bcrypt、argon2 他）がある場合、それを IdP へ直接インポートし、検証できますか？
可能なら、ユーザー体験は一切変わらず、最善です。
不可能なら「パスワードリセットメール配布」となり、全ユーザーの30-50%を失うリスクが現実になります。
2. 漸進的（レイジー）マイグレーション
一括移行せず、ユーザーが初回ログイン時ごとに旧システムに問い合わせ、新 IdP にユーザーを作る。その後は新 IdP のみ使用。
大規模ユーザー基盤では最も安全ですが、以下要件が必要：
3. 並行運用（デュアルライト）
新旧 IdP 両方を同時稼働。書き込みは両方、読み込みは徐々に新側へ移行。ロールバック可能ですが、運用が複雑化します。
ベンダーが即答できなければ、実績がないので次を検討しましょう。
B2B SaaS ＝マルチテナンシー。顧客は組織単位で複数ユーザー・ロール・アクセスポリシーを求めます。IdP がこれを本質的に理解し実装していることが大前提です。
組織モデルがネイティブでない IdP は、user.app_metadata.org_id = "123" のようなカスタムメタデータに格納することを提案します。
すぐ破綻します：
ベンダーが「メタデータで組織をモデリングできます」と言ったら、それはリレーショナルデータを JSON カラムで持つのと同等です。「動くうちは良いが、限界がすぐ来る」。
12 ヶ月前には「AI エージェント認証」はどの評価リストにもありませんでした。今は、コラボレータやエージェント、AIワークフローを組み込むなら新しい「エージェント」型アイデンティティを管理できる IdP が不可欠です。
これまでは「ユーザー」と「アプリケーション」の二者のみが認証主体。OAuth2 はこの前提に設計されています。
AI エージェントは第３の存在：非人間エンティティが特定ユーザーの代理で、限定された権限・監査証跡付きで操作する必要が出てきました。
Token Exchange (RFC 8693)： エージェントが自分のクレデンシャル + ユーザーの認可情報を提示し、限定されたトークンを受け取る。トークンには「誰が（ユーザー）、誰が代理（エージェント）、範囲（スコープ）、有効期間」全て含める必要あり。
エージェントをクライアント型としてモデリング: エージェントは固有の client_id を持つ正規の OAuth2 クライアント型として表現できるべきで、API キーや共有ユーザートークンの使い回しでは不十分。
委譲スコープ管理: ユーザーがエージェントに権限を明示的に付与でき、アクセス可能リソースや許可範囲を限定可能か。
監査の明確化: ログで「ユーザー本人の操作」と「エージェントが代理で操作」の区別ができるか。これができないと次回 SOC2 監査で「誰がこの変更を？」と聞かれて困ることになります。
MCP は AI エージェントがツールやサービスと連携する標準プロトコルになりつつあります。IdP が OAuth ベース認証で MCP サーバーと連携できれば、API キーや共有シークレットでなく正式なプロトコルレイヤーでエージェント認証が可能です。
ベンダーがこの領域を考えていないなら、それは 2020 年向けの製品です。あなたは 2026 年に備えているはずです。
機能が売れても、運用でリピートするかが決まります。
全ての評価軸で比較した後、判断基準となる優先度フレームワークは次の通りです：
| 基準 | なぜP1か |
|---|---|
| パスワードハッシュインポート or 漸進移行 | 移行できないなら意味がない |
| Authorization Code + PKCEサポート | セキュリティ必須 |
| ネイティブ組織モデル | B2B SaaS 基本要件 |
| SOC2 Type II または明確な取得予定 | エンタープライズ顧客対応 |
| 99.9%以上の稼働SLA | Auth 止まる＝全サービスダウン |
| 基準 | なぜP2か |
|---|---|
| カスタムJWTクレーム | 毎回APIコールせず認可判断可能 |
| 組織ごとの認証ポリシー | エンタープライズ顧客対応 |
| 組織スコープのロール・トークン | マルチテナント認可運用 |
| リフレッシュトークンローテ・失効 | セキュリティベストプラクティス |
| ホステッドUIと自前UI選択 | ユースケースごとに選べる柔軟性 |
| 基準 | なぜP3か |
|---|---|
| トークン交換（RFC 8693） | AIエージェント認証 |
| OIDC Provider 機能 | パートナー連携・フェデレーション |
| ステップアップ認証／auth_level | 金融・高リスク操作用 |
| SCIMプロビジョニング | 企業ディレクトリ連携 |
| パスキー／WebAuthn | パスワードレス方向 |
| 基準 | なぜP4か |
|---|---|
| 内蔵アナリティクス | 監査ログから自作可能 |
| ホワイトラベルメールテンプレ | 便利機能 |
| ビジュアルフロービルダー | 便利機能 |
| 主要以外SNSコネクタ多数 | ロングテール需要 |
使い方：まずP1全クリア必須。いずれかNGなら評価中止。P2・P3を加点式で比較。一番合計得点の高いベンダーが最適です。
私たちは現場で同じミスが繰り返されるのを見てきました。主なものと対策：
機能比較表は「何があるか」は教えますが、「どう実装されているか」は分かりません。IdP が「組織対応」と言っても、ユーザーメタデータ内のID管理だけなら本番運用では確実に難航します。
対策：「これを実際にはどう実装していますか？」を常に質問しましょう。
最適と思った IdP を選んだ後で、ユーザー全員パスワードリセットが必要と判明—すでに実装を始めた後で気づくと手詰まりです。
対策：最初のフィルターに「移行性」を設定しましょう。
どのベンダーのデモも美しく作り込まれています。クリーンなDB・例外ゼロのハッピーパスだけ。「本番」には結合アカウント・プロファイルの変なユニコード・不良セッションも山ほどあります。
対策：実データ1,000件を使ったPoCの提供を依頼しましょう。
プラットフォームチームだけで決めれば「技術的にキレイ」な案を選びます。プロダクトだけなら「統合しやすい」方に。セキュリティだけなら「コンプライアンス最優先」案に。
対策：プラットフォームエンジニア・プロダクト・セキュリティの横断チームで評価しましょう。それぞれP1/P2を担当する項目が異なります。
ベンダーロックインは現実です。独自SDKやAPI、非標準トークン— これらは将来の移行を困難にします。
対策：標準プロトコル（OIDC, OAuth2, SCIM）を採用する IdP を優先しましょう。将来必ず役に立ちます。
PoC テスト含む本格評価なら4～8週間見込み。急ぐと特に移行性で失敗します。要件定義2週間、ベンダー評価／PoC 2-3週間、関係者調整1-2週間を目安に。
1万人未満＆エンタープライズ顧客なしなら、軽量認証ライブラリで十分。ただし、SSO・マルチテナンシー・MFA・コンプラ書類等が必要になると自作の保守コストは専門ベンダー利用を超えます。エンジニア2-3人分の工数（年間 300-500 万ドル以上）が掛かることも。
CIAM（Customer Identity and Access Management）はプロダクトのエンドユーザー側。ワークフォース IAM は自社社員が社内ツールを使うためのもの（Okta、Google Workspace など）。要件が異なり、選定軸も変わります。このガイドはCIAM向けです。
オープンソース IdP は透明性（コード監査可能）、ポータビリティ（自社ホスト可能）、コミュニティ貢献などの利点。商用 IdP はUIやマネージドサービスが強み。重要なのは「オープンかクローズか」でなく「必要なら抜けられるか」。データモデルとAPI公開済みの OSS は将来の移行も容易です。
既にAIと連携しユーザーデータ代理利用する（コパイロット、自動化フロー、AIアシスタント等）なら今すぐP1に。6~12ヶ月のロードマップにAIがあるならP3だけど重視。全く予定なしでも6ヶ月ごとに見直しましょう。
多くの IdP は月間アクティブユーザー（MAU）課金モデルですが、MAU の定義（ログイン件数・一意ユーザー・M2Mトークンを分離するか等）が異なります。必ず自社の前提（ユーザー数、組織数、M2M接続数、認証ボリューム）で各社見積りを取り、単価でなく総額で比較しましょう。
アイデンティティプロバイダの選定は「機能」より「インフラ」決定事項です。全ユーザーが最初に触れる窓口、API のすべての認可判定、コンプライアンス部門がチェックする監査ログもこの基盤に依存します。
上記フレームワークは本当に重要な基準のみを網羅し、マーケティングの箇条書きにはない落とし穴を防げます。すべての候補を素早く（P1）、深く（P2/P3＋PoC）検証し、「何年も運用できる答え」へと導きます。
正しくこの選定ができたチームに共通するのは、「アイデンティティをインフラの一部」と見なし、「出荷して忘れる機能」として扱わなかった点です。