IdP
Identity Provider ・ あいでぃーぴー
利用者の台帳を一元管理し、ログインの証明と各サービスのアカウント配布を担う認証の元締め。
✦ 30秒で試す — 航海入口は1か所で閉めた。でも裏口はまだ開いている退職者は、チャットにいつまで入れる？予想してみる概要
IdP（Identity Provider、アイデンティティプロバイダ）は、組織の利用者の身元を一元的に管理し、各サービスに代わって「この人は確かに本人です」と証明する、認証の元締めです。社員が Slack にも Google Workspace にも GitHub にも同じ会社アカウントでログインできるとき、その裏で本人確認を一手に引き受けているのが IdP です。IdP の証明を受け取って利用する側のサービスは SP（Service Provider、サービスプロバイダ）と呼ばれます。SP は自前でパスワードを預からず、「IdP が本人だと言うなら信じる」という信頼関係を IdP との間に結びます。
IdP には、性格の違う2つの顔があります。1つ目は認証の窓口です。ログインのたびに本人を確かめ（パスワード、MFA、端末の状態など）、その結果を署名付きの証明にして SP へ渡します。一度のログインで複数のサービスに入れる SSO（シングルサインオン）は、この顔が生む体験です。2つ目はディレクトリとプロビジョニングです。「この組織に誰がいて、どの部署に属し、どのサービスを使ってよいか」という台帳を持ち、その内容に合わせて各サービスのアカウントを作り、変え、止めます。前者は「いまログインしようとしているのは本人か」に答え、後者は「そもそもこの人はここにいてよいのか」に答えます。
代表的な製品には Okta、Microsoft Entra ID（旧 Azure AD）、Google Workspace の ID 管理、オープンソースの Keycloak などがあります。「Google でログイン」「Apple でサインイン」のように、一般消費者向けのサービスが個人のアカウントを証明する場合も、Google や Apple は IdP として振る舞っています。企業のセキュリティ設計では「どの IdP を中心に据えるか」が最初の大きな意思決定のひとつです。
なぜ生まれたか
IdP という役割が確立する前、各サービスはそれぞれ独自に利用者のデータベースとパスワードを持っていました。社員が10個のツールを使えば、アカウントも10個、パスワードも10個です。利用者は覚えきれずにパスワードを使い回し、管理者は入社のたびに10箇所でアカウントを作り、退職のたびに10箇所で消す必要がありました。1つでも消し忘れれば、退職者のアカウントが生きたまま放置されます。これは実際に多くの情報漏えいの入口になってきました。
最初の解決は、台帳を一箇所にまとめることでした。1990年代に標準化された LDAP（ディレクトリにアクセスするプロトコル）と、2000年に登場した Microsoft の Active Directory は、社内の利用者とグループを一つのディレクトリで管理し、社内システムの認証をそこへ集めました。ただし、これが通用したのは社内ネットワークの中だけです。2000年代以降、クラウドの SaaS を使うことが当たり前になり、利用するサービスが数十〜数百に膨らむと、社外にあるサービスへ「社内の台帳で確かめた本人」をどう伝えるかが新しい課題になりました。
そこで、ネットワークの境界を越えて「本人確認の結果」を運ぶ標準が生まれます。2005年の SAML 2.0、2014年の OIDC（OpenID Connect）が証明の受け渡し方を定め、異なる会社のサービス同士でも、認証を専門に担う IdP と、その結果を信頼する SP という分業が成り立つようになりました。これが SSO の土台です。さらに2015年には、台帳の変更（作成・更新・停止）をサービスへ届ける SCIM 2.0（RFC 7643／7644）が標準化され、ログインだけでなくアカウントの一生そのものを IdP から管理できるようになりました。
詳細
2つの顔と2本の経路
IdP と SP の関係は、「IdP が SP に直接ログインを通知する」ものだと思われがちですが、実際は違います。ログインの証明は、利用者のブラウザが運びます。利用者が SP にアクセスすると、SP はブラウザを IdP へリダイレクトさせます。IdP が本人を確かめると、「認証済み」という証明を持たせてブラウザを SP へ送り返します。証明は IdP の秘密鍵で署名されており、SP は IdP の公開鍵で検証して、改ざんされていない本物であることを確かめます。そのうえで SP は自分のセッションを開始し、以後は Cookie でその利用者を覚えます。パスワードは一度も SP に渡りません。
証明の中身と運び方は、プロトコルによって少し違います。SAML ではアサーション（XML の証明書面）そのものをブラウザがフォームで SP へ POST します。OIDC の認可コードフローでは、ブラウザが運ぶのは引換券の認可コードで、SP はそれをサーバ間の裏口で IdP に渡し、ID トークン（JWT 形式の証明）を受け取ります。どちらでも、ログインはブラウザの往復で始まり、IdP から SP へ一方的に押し込まれることはありません。
これに対して、ディレクトリの顔が使う経路は裏口だけです。SCIM は IdP から SP の API へ直接 HTTPS で「このユーザーを作る」「このユーザーを停止する」と送ります。ブラウザも利用者も関わりません。つまり SP の中には、IdP から来た2種類のものが別々に住んでいます。ブラウザ経由の証明から生まれたセッションと、裏口のプロビジョニングで作られたアカウントです。この区別が、後で見る退職時の後始末の鍵になります。
認証の窓口 — 一箇所で強制できるもの
認証が一箇所に集まると、セキュリティの方針もその一箇所で決めれば全サービスに効くようになります。代表例が MFA（多要素認証）です。SP ごとに MFA の対応状況を調べて個別に設定する代わりに、IdP のログインで MFA を必須にすれば、配下のすべての SP が自動的に MFA で守られます。「社外のネットワークからは追加の確認を求める」「会社が管理していない端末からは入れない」といった条件付きアクセス（状況に応じて認証の強さを変える仕組み）も、IdP で一括して制御できます。
この「アクセスのたびに IdP が本人と端末の状態を確かめる」構図は、社内ネットワークにいること自体を信用しないゼロトラストの中核部品でもあります。ゼロトラストの文脈では、IdP は単なるログイン画面ではなく、すべてのアクセス判断に「誰が・どの端末で」という根拠を供給する中枢として位置づけられます。
ディレクトリとプロビジョニング — 台帳を全サービスへ届ける
ディレクトリは、認証の判断も認可の判断も最終的に依存する台帳です。多くの組織では人事システムを「正」とし、入社・異動・退職の情報を人事システムから IdP へ流し込みます。台帳にはグループ（「営業部」「本番環境の管理者」など）も載り、SP 側ではこのグループをロールに対応づけて、RBAC（ロールに基づくアクセス制御）の権限を決めます。部署を異動すればグループが変わり、各サービスでの権限も自動で入れ替わる、という流れです。
台帳の変更を SP へ届ける方法は、大きく2つあります。1つは JIT（Just-In-Time）プロビジョニングで、利用者が初めて SSO でログインしてきた瞬間に、証明に含まれる属性からアカウントを作ります。手軽ですが、作ることはできても消すことはできません。退職者はもうログインしてこないので、SP には知らせが届かないからです。もう1つが SCIM で、IdP が台帳の変化を検知して SP の API を呼び、アカウントの作成・更新・停止を能動的に行います。退職者の処理まで自動にしたいなら、SCIM が必要です。
退職の日に何が起きるか
一元化の価値がいちばんはっきり見えるのが、社員の退職です。人事システムで退職日が来ると、IdP でその人のアカウントが無効になります。ここから先は、SP が SCIM に対応しているかどうかで結果が分かれます。
IdP を止めることで確実に止まるのは、これから行われるログインです。一方、SP がすでに発行したセッションは、SP の中に住んでいて、有効期限まで IdP に問い合わせずに使われ続けます。チャットのモバイルアプリのように、セッションを数週間保つサービスも珍しくありません。さらに、IdP を通らないログイン経路が残っている SP もあります。SSO の導入前に作られた「ローカルアカウント」（その SP が自前でパスワードを持つアカウント）や、SSO と並行してパスワードでもログインできる設定です。こうした経路には、IdP の停止はまったく届きません。個人アクセストークンや API キーのように、ログインとは別に発行された資格情報も同じです。
対策は、この「IdP の外に残るもの」を一つずつ減らすことです。SCIM に対応した SP では、停止と同時にセッションも切れることが多いですが、実装によっては切らないものもあるため確認が必要です。SP で SSO を強制してパスワードでのログインを無効にし、ローカルアカウントを棚卸しします。SCIM に対応していない SP は、退職時の手作業のチェックリストに残します。セッションの長さも、利便性と退職時の遅れとの天秤です。IdP からのシグナルで SP のセッションを即座に切る仕組み（OpenID の Shared Signals Framework など）も広がりつつあります。
下の部品で確かめてください。社員カードを「退職」欄へ運ぶと、構成ごとに、IdP の一度の操作で閉じたサービスと、朱に光って残るもの（アカウントと生きたセッション）が分かれます。時間を進めてセッションが切れたあとの動きや、残りを手で消す回数も比べてみてください。
退職する社員のカードを1枚つかんで、左の「退職」欄へドラッグしてください（タップでも運べます）。上の切り替えで、会社の ID 管理の構成を選べます。
機械のアイデンティティ
IdP の対象は人間だけではありません。バッチ処理や CI/CD のパイプラインが使うサービスアカウント、API 同士の呼び出しなど、機械のアイデンティティをどこまで IdP に寄せるかも設計の論点です。近年は、CI のジョブに長期間有効な鍵を持たせる代わりに、CI 基盤が発行する短命の OIDC トークンをクラウド側が検証して一時的な権限を渡す方式（ワークロード ID 連携）が広がっています。ここでは CI 基盤そのものが「このジョブは、このリポジトリのこのブランチで動いている」と証明する IdP の役を担っています。
実務での使いどころと落とし穴
実務では、SaaS を導入するたびに「SAML／OIDC による SSO に対応しているか」「SCIM に対応しているか」を確かめ、IdP に SP として登録していくのが定石です。ただし、SaaS によっては SSO や SCIM を上位の料金プランでしか提供しておらず（「SSO 税」と揶揄されます）、全サービスを IdP につなぐにはコストがかかります。どのサービスまで一元化するかは、扱うデータの重要度とのバランスで決めることになります。
最大の落とし穴は、IdP が単一障害点であり、しかも攻撃者にとって最も価値の高い標的になることです。IdP が落ちれば全サービスにログインできなくなり、IdP が破られれば全サービスへの扉が開きます。大手 IdP ベンダーの Okta 自身も、2022年と2023年に侵害を受けています。IdP の管理者アカウントには、フィッシングに強い MFA と最小権限での運用が欠かせません。管理操作の監査ログの監視と、IdP が使えなくなったときのための緊急用アカウント（ブレークグラスアカウント）の整備も必須です。「認証を一箇所に集める」という設計は、利便性と統制の大きな利得と引き換えに、その一箇所を組織で最も堅牢な場所にする責任を負う選択なのです。
試問
社員のログインを引き受ける IdP と、4つのサービス（チャット・コード管理・経費精算・旧 Wiki）が並んでいます。社員カードを「退職」欄へ運ぶと、構成ごとの後始末が走り、退職者の手元の端末から各サービスに入れるかを確かめます。「時間を進める」でログイン状態の期限を進め、朱に光るサービスを押すとそのアカウントを手で消せます。
退職する社員のカードを1枚つかんで、左の「退職」欄へドラッグしてください（タップでも運べます）。上の切り替えで、会社の ID 管理の構成を選べます。