IdP

概要

IdP（Identity Provider、アイデンティティプロバイダ）は、組織内のユーザーの身元情報を一元管理し、「この人は確かに本人です」という証明を各サービスに代わって発行する認証の元締めです。社員が Slack にも Google Workspace にも GitHub にも同じ会社アカウントでログインできるとき、その裏で本人確認を一手に引き受けているのが IdP です。

IdP に対して、認証結果を受け取る側のサービス（Slack や GitHub など）は SP（Service Provider、サービスプロバイダ）と呼ばれます。SP は自前でパスワードを預からず、「認証はあちらの IdP にお任せしています。IdP が本人だと言うなら信じます」という信頼関係を IdP との間に結びます。この役割分担が、SSO（シングルサインオン）や全社的なアクセス管理の土台になっています。

代表的な製品には Okta、Microsoft Entra ID（旧 Azure AD）、Google Cloud Identity、オープンソースでは Keycloak などがあります。企業のセキュリティ設計では「どの IdP を中心に据えるか」が最初の大きな意思決定のひとつです。

なぜ生まれたか

IdP という役割が確立する前、各サービスはそれぞれ独自にユーザーデータベースとパスワードを持っていました。社員が10個のツールを使えば、アカウントも10個、パスワードも10個。ユーザーは覚えきれずにパスワードを使い回し、管理者は入社のたびに10箇所でアカウントを作成し、退社のたびに10箇所で削除する必要がありました。削除漏れがあれば、退職者のアカウントが生きたまま放置される — これは実際に多くの情報漏えい事故の入口になってきました。

SaaS の普及で利用サービス数が数十〜数百に膨らむと、この「サービスごとにバラバラの身元管理」は運用としてもセキュリティとしても破綻します。そこで「本人確認とアカウント管理は一箇所に集約し、各サービスはその結果だけを受け取る」という分業が生まれました。認証を専門に担う側が IdP、それを信頼して利用する側が SP です。SAML や OIDC といった標準プロトコルが両者の間の「証明の受け渡し方」を定めたことで、異なるベンダーのサービス同士でもこの分業が成立するようになりました。

詳細

IdP と SP の役割分担

IdP を中心に置いた構成では、ユーザー・IdP・SP の三者関係が基本形になります。ユーザーが SP にアクセスすると、SP は自分でログイン画面を出さず、ユーザーを IdP へ送り出します。IdP が本人確認を済ませると、「認証済みである」という署名付きの証明（SAML ならアサーション、OIDC なら ID トークン）を発行し、ユーザー経由で SP に渡します。SP は署名を検証して証明を受け入れ、自サービスのセッションを開始します。パスワードは一度も SP に渡らない、という点がこの構造の核心です。

受け渡しのプロトコルとしては、企業向け SaaS では歴史の長い SAML が、モバイルアプリやモダンな Web サービスでは OAuth の上に認証層を載せた OIDC が使われます。多くの IdP は両方に対応しており、SP 側の対応状況に合わせて使い分けるのが一般的です。

ディレクトリ — 「誰がいるか」の台帳

IdP の中核にあるのはディレクトリ、つまり「この組織に誰がいて、どの部署に所属し、どんな属性を持つか」の台帳です。オンプレミス時代の Active Directory や LDAP がこの役割を担ってきましたが、クラウド IdP はこれをクラウド側に持ち、人事システムと連携して入社・異動・退社を自動反映させます。認証の判断も認可の判断も、最終的にはこの台帳の正しさに依存するため、ディレクトリを常に現実と一致させることが ID 管理の生命線です。

台帳の変更を各 SP に伝える仕組みが「プロビジョニング」で、標準プロトコルとして SCIM（System for Cross-domain Identity Management）があります。IdP でユーザーを作成すれば SCIM 経由で各 SP にアカウントが自動作成され、無効化すれば全 SP から一斉に消える。冒頭で触れた「退職者アカウントの削除漏れ」という古典的リスクは、この自動化によって構造的に潰せます。ログイン経路の一元化（認証）と、アカウントのライフサイクル管理（プロビジョニング）は IdP の両輪です。

ポリシーの一元適用 — MFA からゼロトラストへ

認証が一箇所に集まると、セキュリティポリシーもその一箇所に適用すれば全サービスに効くようになります。代表例が MFA（多要素認証）です。SP ごとに MFA 対応状況を調べて個別に設定する代わりに、IdP のログインに MFA を必須化すれば、配下のすべての SP が自動的に MFA で守られます。さらに「社外ネットワークからのアクセスには追加確認を求める」「管理されていない端末からは接続させない」といった条件付きアクセス（コンテキストに応じた認証強度の調整）も IdP 側で一括制御できます。

この「アクセスのたびに IdP が本人と端末の状態を検証する」という構図は、社内ネットワークにいること自体を信用しないゼロトラストアーキテクチャの中核部品でもあります。ゼロトラストの文脈では、IdP は単なるログイン窓口ではなく、全アクセス判断の根拠を供給するポリシー決定の中枢として位置づけられます。

実務での使いどころと落とし穴

実務では、SaaS を導入するたびに「SAML/OIDC 対応か」「SCIM プロビジョニング対応か」を確認し、IdP に SP として登録していくのが定石です。人間のユーザーだけでなく、バッチ処理や CI が使うサービスアカウントや、API 間の機械同士の認証をどこまで IdP に寄せるかも設計論点になります。

最大の落とし穴は、IdP が単一障害点かつ最重要標的になることです。IdP が落ちれば全サービスにログインできなくなり、IdP が破られれば全サービスへの扉が開きます。実際、大手 IdP ベンダー自身への侵害事件も起きており、IdP 管理者アカウントの厳重な保護（フィッシング耐性のある MFA、最小権限での運用）、監査ログの監視、緊急用のブレークグラスアカウント（IdP 障害時の予備手段）の整備は必須です。「認証を一箇所に集める」という設計は、利便性と統制の大きな利得と引き換えに、その一箇所を組織で最も堅牢な場所にする責任を負う選択でもあります。