フェデレーション認証とは？IdPとSPの信頼設計と属性連携を実装視点で解説

自社サービスに「顧客企業のIdPでログインさせたい」という要件が来たとき、実装の難所はプロトコルの選択ではありません。誰と、どの範囲で、いつまで信頼を結ぶかという取り決めのほうです。フェデレーション認証は、認証そのものを別の管理主体へ委ね、その結果と属性だけを受け取る仕組みで、SSOとは別の層にある概念です。本記事では、信頼委譲という技術的な境界から定義を整理し、IdPとSPが交換するメタデータの中身、署名証明書の切り替えで接続が一斉に落ちる条件、SAMLとOIDCの適用条件、アカウント紐付けとプロビジョニングの分担、そして採用を見送るべき条件までを実装の順序で扱います。

まとめ：フェデレーション認証の採否判断と設計で先に決める3点

結論を先に置きます。自社サービスの利用者が法人の従業員で、その所属企業がIdPを持っているなら、フェデレーション認証は入れる価値があります。パスワードを自社DBに置かずに済み、退職者の締め出しが顧客企業側の操作だけで完了するためです。

設計で先に決めるべきは3点です。ひとつめは、利用者を一意に識別する主キーをどの値にするか。SAMLのNameIDやOIDCのsubを使い、メールアドレスは表示用の属性として扱います。ふたつめは、アカウントの作成と削除をJITプロビジョニングで賄うか、SCIMで別経路に切り出すか。みっつめが署名鍵の更新の吸収方法で、OIDCならJWKSの参照で自動追随できる一方、SAMLは事前のメタデータ交換に依存するため切り替え日の調整が運用手順として要ります。

見落とされやすい前提もひとつ。シングルログアウトは完走しません。通知が全SPへ確実に届く保証はなく、片方だけセッションが生き残る状態が常態です。この前提でセッション寿命を短く設計しておかないと、退職者が数時間ログインできてしまう穴が残ります。

フェデレーション認証の定義とSSO・ID連携との技術的な境界線

言葉の範囲がずれたまま要件定義に入ると、後工程で「これはSSOなのかフェデレーションなのか」という議論が再燃します。境界を先に固めます。

認証結果と属性を別の管理主体へ引き渡す信頼委譲という定義の範囲

フェデレーション認証とは、あるシステムが利用者の認証を自前で行わず、別の管理主体が出した認証結果を検証して受け入れる構成を指します。認証する側をIdP（Identity Provider）、受け入れる側をSP（Service Provider、OIDCの語ではRP＝Relying Party）と呼びます。

判定基準はひとつだけ。パスワードなどの資格情報がSP側を通過するかどうかです。SPが受け取るのは、IdPが署名した「この利用者は認証済みで、属性はこうだ」という主張（SAMLではAssertion、OIDCではIDトークン）だけ。SPは署名を検証して主張を信じます。つまりフェデレーションの実体は、認証プロトコルではなく署名検証によって成立する信頼関係のほうです。後述する証明書ローテーションや信頼解除が設定変更ではなく運用設計の問題になるのは、この一点に由来します。

SSOとの違いを分ける「体験の統合」と「信頼の委譲」という別レイヤ

SSOとフェデレーションは、対立する2つの方式ではありません。層が違います。SSOは「1回のログインで複数のサービスへ入れる」という利用者から見た体験を指す言葉で、フェデレーションはその体験を成立させる手段のひとつです。

手段は他にもあります。代理認証（IDとパスワードを代理送信する方式）やリバースプロキシ型は、フェデレーションを使わずにSSOを実現します。これらは既存アプリを改修せずに済む反面、パスワードをどこかに保管し続ける点が構造的な弱みです。実現方式ごとの向き不向きはシングルサインオン（SSO）の4つの実現方式とIdP選定で比較しているので、要件がSSOで止まっているのか、組織をまたぐ信頼まで必要なのかを先に切り分けてください。

IdPとSPが信頼を確立するメタデータ交換と署名鍵の運用要件

接続作業の実務は、プロトコルの実装よりも相手と何を取り決めるかに時間を取られます。

SAMLメタデータのEntityIDとACS URLで取り決める接続情報の一覧

SAML 2.0系での接続は、双方がメタデータXMLを交換するところから始まります。顧客企業のIdP管理者とやり取りする項目は、実質この順序で固まります。

1. EntityID（SPを識別する文字列。自社サービスのURLを使うのが慣例）
2. ACS URL（AssertionConsumerService。IdPが署名済み主張をPOSTしてくる自社側の受け口）
3. 署名検証用のIdP公開鍵証明書と、その有効期限
4. NameIDフォーマット（persistentかemailAddressか。ここの合意が後の紐付け設計を決める）
5. 送出してもらう属性の名前と値の形式（部署、ロール、社員番号など）

実務で揉めるのは4番と5番です。IdP側の管理画面では属性名が製品固有の表記になっていることが多く、SP側が期待する名前と一致しません。接続テストの前に属性名の対応表をテキストで確定させておくと、往復が1回で済みます。証明書の有効期限も、この時点で必ず控えておいてください。

OIDCディスカバリとJWKS参照で鍵更新を自動追随させる構成の要件

OIDC 1.0系には、メタデータ交換に相当する仕組みが標準で入っています。IdPが公開するディスカバリ文書（well-known配下のJSON）に、認可エンドポイント、トークンエンドポイント、署名鍵を配布するJWKSエンドポイントのURLが並びます。

SP側は起動時と定期的にJWKSを取得し、IDトークンのヘッダにあるkidと突き合わせて検証鍵を選びます。この構成なら、IdPが鍵を追加しても、SPは次回のJWKS取得で自動的に追随します。手動での証明書配布が不要になる点が、SAMLとの最大の運用コスト差です。プロトコル自体の構造とOAuth 2.0との関係はOIDC（OpenID Connect）の仕組みとOAuthとの違いで整理しています。

ただし自動追随には条件があります。JWKSのレスポンスを長時間キャッシュしたまま更新しない実装だと、鍵の入れ替え直後に検証が全滅します。未知のkidを受け取ったときだけJWKSを再取得する経路を入れ、その再取得にはレート制限をかけてください。攻撃者が偽のkidを送り続けてIdPへのリクエストを増幅させる経路を塞ぐためです。

署名証明書のローテーションで全SPが同時停止する条件と回避の手順

フェデレーション基盤で最も多い障害はこれです。IdPの署名証明書には有効期限があり、切れれば全SPで検証が失敗します。SAMLではSPが証明書を設定として保持するため、IdP側の切り替えと同時に、更新していないSPが一斉に落ちます。

回避の要点は、切り替えを瞬間ではなく期間にすることです。SAMLメタデータは複数の署名用証明書を並べて記述でき、SP側が複数鍵に対応していれば新旧を並行して有効にできます。新旧併記に対応しないSP実装は同時切り替えを強制してくるので、接続開始時の確認項目に入れてください。

運用側では、証明書の有効期限をカレンダーではなく監視に載せ、期限の60日前と14日前に警告を出します。切り替え作業そのものは業務時間外を避ける。障害時にIdP管理者へ連絡できる窓口を接続開始時点で取り決めておくかどうかで、復旧までの時間が数十分と数日に分かれます。

プロトコル選定：SAMLとOIDCの適用条件と開始経路2種の実装差

どちらを実装するかは好みではなく、接続先の顔ぶれで決まります。判断軸を5つに絞ります。

SAML 2.0系とOIDC 1.0系の適用条件を分ける5つの比較軸

結論から言えば、これから作るWebサービスの標準経路はOIDCです。JSONとHTTPだけで完結し、モバイルアプリやSPAにも同じ仕組みで対応できます。それでもSAMLを捨てられない理由は、接続してくる顧客企業側のIdPと運用者の習熟にある点です。SAMLの認証フローとIdP・SPの役割分担はSAMLの認証フローとIdP・SPの仕組みで個別に解説しています。

表の工数は、既存のログイン機能がある前提での追加分です。判断は単純で、法人向けSaaSとして不特定多数の企業を受け入れるなら両方を実装します。片方だけにすると、接続できない顧客が出た時点で商談が止まるためです。

SP-initiatedとIdP-initiatedの選択とリプレイ耐性という設計差

認証の開始地点は2種類あります。自社サービスのURLへ来た利用者をIdPへ飛ばすSP-initiatedと、IdPのポータルのアイコンから自社サービスへ入ってくるIdP-initiatedです。

実装の既定値はSP-initiatedにしてください。理由はリプレイ耐性の差です。SP-initiatedではSP側がリクエストIDを発行して保持し、返ってきた主張のInResponseTo値と突き合わせられます。IdP-initiatedにはこの往復がなく、SPは未知の主張をいきなり受け取るため、再送を検知する手掛かりが減ります。

とはいえIdP-initiatedの要望は現場から必ず出ます。顧客企業のポータルに自社サービスのタイルを並べたいという要求です。受ける場合は、主張のID（SAMLならAssertionのID、OIDCならIDトークンのjti）を有効期間中は保存して再利用を弾き、有効期間そのものを数分に絞る。加えて、着地先を示すRelayStateはSPが持つ許可リストの値だけに制限してください。任意のURLを受け取ると、オープンリダイレクトの経路になります。

属性マッピングとアカウント紐付けにおけるJITとSCIMの分担

プロトコルが繋がった後に効くのは、受け取った属性を自社のユーザーテーブルへどう落とすかです。ここの設計ミスは数か月後にデータ移行として跳ね返ります。

NameIDとsubの選定でメールアドレスを主キーにしない技術的な理由

結論を先に書きます。利用者の主キーには、IdPが発行する不変の識別子を使ってください。SAMLならpersistent形式のNameID、OIDCならIDトークンのsubです。

OpenID Connect Core 1.0（errata set 2、2023年12月15日発行）は、subを「Issuer内で一意であり、再割り当てされない識別子」と定めています。仕様として不変性が保証されている値は、実務上ここだけです。対してメールアドレスは変わります。結婚による姓の変更、部署異動による命名規則の変更、企業のドメイン統合。どれも数年に一度は起きる事象で、そのたびに同一人物が別アカウントとして作られます。

すでにメールアドレスを主キーにしている既存サービスにフェデレーションを足す場合は、初回ログイン時だけメールで既存アカウントを照合し、以後はsubを主キーとして保存する移行経路を作ります。この照合には条件を付けてください。IdPがメールの所有を検証済みであること（OIDCならemail_verifiedが真であること）を確認せずに突き合わせると、他人のアカウントを乗っ取れる経路になります。

JITプロビジョニングの限界とSCIM 2.0へ切り替える判断基準

JIT（Just-In-Time）プロビジョニングは、初回ログインの主張に含まれる属性からアカウントを自動作成する方式です。実装は軽く、フェデレーションの接続だけで完結します。

限界はふたつあります。ログインしない利用者はいつまでも作られないこと、そして退職者のアカウントが消えないことです。JITは作成の契機しか持たないため、削除と無効化の経路が存在しません。IdP側で無効化された利用者はログインできなくなりますが、SP側のレコードは残り続け、ライセンス数の集計や監査でずれます。

切り替えの判断基準は明快です。接続先1社あたりの利用者が数百人を超える、利用者の入れ替わりが月次で発生する、ライセンス課金がユーザー数に連動する。このいずれかに当てはまったらSCIMを実装します。SCIMはRFC 7644（2015年9月・コアスキーマはRFC 7643）で定義され、IdPからSPへユーザーとグループの作成・更新・削除をHTTPで送り込む別経路の仕様です。エンドポイントの実装範囲と作り方はSCIMによるID自動プロビジョニングとエンドポイント実装にまとめています。

両者は排他ではありません。SCIMで日次同期を回しつつ、SCIM未対応のIdPからの接続だけJITで受ける二本立ては現実的な構成です。

マルチテナントSaaSでテナント別IdPを受け入れる設計と実装の順序

自社サービスが複数の顧客企業を相手にする場合、IdPは1つではなく顧客の数だけ存在します。この前提が設計を一段複雑にします。

メールドメインからIdPを解決するホームレルムディスカバリの実装

ログイン画面に立った利用者を、どのIdPへ飛ばすか。この解決処理をホームレルムディスカバリと呼びます。実装の定石は、パスワード欄を出さずにメールアドレスだけを入力させ、そのドメインでテナントを引き当ててIdPへリダイレクトする形です。

設計上の注意は3つ。第一に、ドメインとテナントの対応表は一意にし、同じドメインを複数テナントが主張してきたら所有権の確認まで登録を保留します。第二に、gmail.comのような共用ドメインは対応表に載せない。第三に、入力されたドメインが未登録だったときの挙動を、自社のパスワードログインへ落とすのか、エラーにするのかを明示的に決めます。ここを曖昧にすると、登録済みユーザーの存在を外部から推測できる差分が出ます。

なお、サブドメインやパスにテナント識別子を含める設計にすれば、ホームレルムディスカバリ自体が不要です。企業向けサービスでは、この割り切りのほうが実装も運用も軽くなります。

シングルログアウトが完走しない前提で置くセッション寿命の設計

SLO（Single Logout）の仕様は存在します。SAML 2.0にはSingle Logout Profileがあり、OIDCにもRP-Initiated・Front-Channel・Back-Channelの各Logout仕様が揃う。それでも実務では完走を前提にできません。

フロントチャネル方式は不可視のiframeで各SPのログアウトURLを叩く構造のため、SameSite属性やサードパーティCookieの制限で通知が落ちます。バックチャネル方式はサーバ間通信なので届きますが、SP側の対応状況がまちまちで、1本でも失敗したときに全体をどう扱うかの規定もありません。

設計はこうします。ログアウトの伝播に依存せず、SP側のセッション寿命を短く保つ。アイドルタイムアウトを30分前後、絶対有効期限を8時間前後に置き、権限に影響する操作の前にIdPへ再認証を要求する（SAMLならForceAuthn、OIDCならprompt=login）。退職者の締め出しを本気でやるなら、SLOではなくSCIMのdeactivateとセッション失効を組み合わせるのが実効的な経路です。

フェデレーション認証を採用しない条件と信頼解除で残る運用の穴

フェデレーションは入れれば安全になる仕組みではなく、信頼を外部へ預ける決断です。預けるべきでない場面があります。

フェデレーション認証を見送るべき3つの条件と代替する認証構成

次のいずれかに当てはまるなら、実装しないほうが総コストは下がります。

• 利用者が個人で、所属組織のIdPを持たないBtoCサービス（IdPがソーシャルログインに限られ、退職連動という最大の利点が消える）
• 接続先が1社だけで、その1社との関係が短期の受託案件（メタデータ交換と証明書運用の固定費が、得られる効果を上回る）
• 自社サービスが金銭の移動や個人情報の一括出力を扱い、IdP側の認証強度を検証も強制もできない（AuthnContextやacrで水準を要求しても申告どおりとは限らない）

3つめは特に線引きが要ります。フェデレーションはIdPの認証強度をそのまま引き継ぐため、IdP側が単要素のパスワード認証のままなら、SP側の保護水準もそこで頭打ちになります。高リスク操作の直前に自社側で追加の認証を挟むか、そもそも自社で会員基盤を持つ判断も選択肢です。外部IdPの受け入れと自社の会員DBを併存させる設計は会員管理システム開発で扱う領域なので、既存の会員基盤に後付けする場合は移行順序の設計から相談してください。

退職・契約終了時に信頼解除が届かない経路と監査ログで問う項目

接続を始める手順は誰でも用意します。解くときの手順を持つ組織は多くありません。

顧客企業との契約が終了したら、SP側でその接続を無効化する必要があります。ところが実装によっては、テナントを解約状態にしてもSAMLの接続設定が残り、IdPから主張を投げれば認証が成立してしまう。解約処理と接続無効化を別フラグで管理していると起きる不整合です。契約状態を認証処理の中で必ず参照する構造にしてください。

監査で確認する項目は4つに絞れます。どのIdPから来た認証か（IssuerまたはEntityID）、どの主張IDを受理したか、属性のどれをアカウントへ反映したか、そして拒否した認証とその理由。特に4つめを記録していないシステムが多く、署名検証の失敗が起きても誰も気付きません。証明書の期限切れは、この拒否ログの急増として最初に現れます。

よくある質問

接続の打ち合わせで繰り返し出る質問を、5つに絞って答えます。

フェデレーション認証とSSOは同じものですか？

同じではありません。SSOは「1回のログインで複数サービスへ入れる」という利用者から見た体験を指し、フェデレーションはその体験を実現する手段のひとつです。代理認証型やリバースプロキシ型のようにフェデレーションを使わないSSOも存在し、逆に接続先SPが1つだけならフェデレーションを入れてもSSOにはなりません。要件定義では「組織をまたいで認証を委ねるのか」と「再ログインを省きたいだけなのか」を分けて確認してください。

SAMLとOIDCはどちらを選べばよいですか？

新規に作るなら既定はOIDCです。JSONとHTTPで完結し、モバイルアプリやSPAにも同じ仕組みで届きます。ただし法人向けSaaSとして不特定多数の企業を受け入れる場合は、両方の実装が現実解です。企業のIdP製品はSAML対応が先行しており、OIDC側は製品と版によって対応範囲に差があるためです。接続先が自社グループなど確定している場合に限り、相手が対応する片方だけで足ります。

IdPが障害で停止したらSPには何もできなくなりますか？

新規ログインは止まります。既存セッションは自社側で保持しているため、寿命が切れるまでは操作を継続できます。セッション寿命を極端に短くする設計は、IdP障害時の全滅リスクと表裏の関係です。復旧手段としては、管理者用の緊急アカウントだけフェデレーションを経由しないローカル認証で持ち、多要素認証と操作ログの監視をかけて例外運用します。全利用者にローカル認証を残すのは、パスワードを自社DBから排除した意味を打ち消します。

自前でIdPを実装するのとIDaaSを使うのはどちらがよいですか？

IdPの自前実装は、よほどの事情がない限り見送ってください。署名鍵の管理、複数プロトコルの実装、SLOやディスカバリへの追随、脆弱性対応が継続的に発生します。SP側（受け入れ側）の実装は自前でも現実的ですが、IdP側は既製のIDaaSに寄せるのが定石です。自社が顧客にIdPを提供する立場である場合だけ、CIAM製品との比較を含めて検討する価値があります。

フェデレーション認証だけで多要素認証の要件を満たせますか？

満たせません。フェデレーションは認証をIdPへ委ねる仕組みで、認証強度そのものを規定しないためです。IdP側が単要素のパスワード認証なら、SPに届く主張も単要素の結果です。要件がある場合は、SAMLのAuthnContextClassRefやOIDCのacr_valuesで水準を要求し、返ってきた値を検証する実装を入れます。ただし申告値の正しさはIdPの実装を信じることになるため、接続要件として文書で担保する運用も併せて用意してください。

関連記事

• IDaaSとは？SSO・IdPとの違いとSAML・OIDC・SCIM連携を実装視点で解説：IdP側を製品で賄う判断に進むときに。
• OAuth 2.0とは？仕組み・認可フローと認証・認可の違いをわかりやすく解説：OIDCの土台になる認可の枠組みを押さえるときに。
• PKCEとは？認可コード横取り攻撃を防ぐcode_verifierの実装と検証設計を解説：モバイルアプリやSPAでOIDCを使う場合の必須対策として。
• CIAMとは？顧客ID基盤の設計と会員DB移行・同意管理を実装視点で解説：自社が顧客IDを預かる側に立つ場合の設計として。
• 認証・ID管理とは？MFA・SSO・OIDC・IDaaSの違いと選定を解説【2026年版】：認証基盤の全体像から選定を始める場合の入口。