社内の認証基盤やクラウドサービスの導入を検討していると、製品資料や社内の打ち合わせで「SSO（シングルサインオン）」と「フェデレーション」という言葉が両方登場します。どちらもログインの一元化にかかわる用語ですが、同じ意味なのか、片方がもう片方を含むのか、関係がはっきりしないまま話が進みがちです。
結論から言えば、この2つは対立する概念ではありません。SSOは「一度のログインで複数のサービスを使える状態」を指し、フェデレーションはその状態を組織やドメインをまたいで実現する「方式」の一つです。フェデレーションは、SSOを実現する手段のなかに含まれます。
本記事では、フェデレーションとSSOの違いを冒頭で整理したうえで、認証連携の仕組み、混同されやすいSAML・OpenID Connect・OAuthの役割の違い（認証か認可か）、フェデレーション以外のSSO実現方式、導入のメリット・デメリットまでを解説します。
目次
一括ダウンロードする
フェデレーションとSSOの違い
フェデレーションとSSOは、同じレイヤーで対立する言葉ではありません。SSOは「一度の認証で複数のサービスにアクセスできる状態」という目的を表し、フェデレーションはその目的を「独立して管理された複数のシステムの間でID情報を連携することで実現する方式」です。マイクロソフトの公式ドキュメントも、フェデレーション方式をSSOを実現するいくつかの方法の一つとして位置づけています。
両者の関係を4つの観点で並べると、次のように整理できます。
| 観点 | 意味 | 目的 | 適用範囲 | 代表的な規格 |
|---|---|---|---|---|
| SSO（シングルサインオン） | 一度のログインで複数サービスを使える「状態」 | ログインの一元化による利便性とセキュリティの向上 | 社内システムから外部SaaSまで、連携の形は問わない | （方式ごとに異なる） |
| フェデレーション | その状態を実現する「方式」の一つ | 独立した組織・ドメインをまたいだID情報の連携 | 別々に管理された信頼ドメインの間での連携に用いる | SAML 2.0、OpenID Connect |
このように、フェデレーションはSSOという目的を叶えるための実装方式の一つです。「SSOとフェデレーションのどちらを選ぶか」という二者択一で捉えるのは適切ではありません。「SSOを、どの方式で実現するか」と考え、クラウドサービスや外部組織との連携ならフェデレーション方式が適している、という関係で捉えるのが正確です。
出典・参考資料（2件）
SSOとフェデレーションそれぞれの意味
ここからは、2つの言葉の定義をもう一段掘り下げ、あわせてよくある誤解を解きほぐします。
SSOとは何か
SSO（シングルサインオン）とは、一度の認証で、連携している複数のサービスやシステムにログインできる仕組みを指します。利用者はサービスごとにIDとパスワードを入力する手間から解放され、管理者はパスワードの使い回しや失念による問い合わせ対応を減らせます。
利用者と管理者の双方に実利があります。利用者は複数サービスのパスワードを覚える負担から解放され、管理者はアカウントの発行・停止や認証の強化を認証基盤側でまとめて行えます。利用するクラウドサービスが増えるほど、この一元化の効果は大きくなります。
フェデレーションとは何か
フェデレーション（Federation）とは、独立して管理された複数のシステムの間で、認証にかかわる情報をやり取りして連携させる方式です。
米国の政府標準であるNISTの文書では、フェデレーションを「ネットワークでつながったシステム間で認証属性や利用者属性を伝えるプロセス」と定義し、認証情報を提供する側をIdP（アイデンティティプロバイダー）、それを受け取って利用する側をRP（リライング・パーティー）と呼んでいます。
かみ砕くと、自社が普段使っている認証基盤（IdP）で一度ログインすれば、その「認証が済んだという事実」を別のサービス（RP、SAMLではSP＝サービスプロバイダーと呼びます）に安全に伝え、そのサービスにもログインできるようにする仕組みです。各サービスがそれぞれパスワードを持つのではなく、信頼できるIdPの認証結果を共有する点に特徴があります。
出典・参考資料（1件）
「SSO＝組織内、フェデレーション＝組織間」は正確ではない
解説記事のなかには、「SSOは一つの組織の中、フェデレーションは組織をまたぐ場合」と線引きするものがあります。わかりやすい説明ですが、これは正確ではありません。SAMLにもとづくSSOは、同じ組織内のシステムでも、別組織のSaaSとの間でも成立するからです。
違いの本質は、組織の内か外かではなく、別々に管理された信頼ドメインの間でID情報を連携しているかどうかです。NISTの定義も、フェデレーションを「別々に管理された複数のRPへIdPが認証属性を提供すること」と説明しています。
自社と外部SaaSのように管理主体が分かれていれば、たとえ一社内の利用であってもフェデレーションの考え方が働きます。「組織内か組織間か」という単純化のまま製品を選ぶと、必要な連携方式を取り違えるおそれがあるため、この点は押さえておきたいところです。
出典・参考資料（1件）
フェデレーション（認証連携）の仕組み
ここからは、フェデレーションが実際にどのように認証を連携させるのかを、登場人物と処理の流れに沿って見ていきます。
登場するのは3者です。ログインしようとする利用者、利用者の身元を確認して認証を行うIdP（アイデンティティプロバイダー）、そして利用者が使いたいサービス（SP：サービスプロバイダー）です。IdPとSPという役割は、フェデレーションの代表的な規格であるSAML（Security Assertion Markup Language）が標準として定めています。認証は、次のような流れで進みます。
まず利用者がサービス（SP）にアクセスすると、SPは利用者をIdPのログイン画面へ転送（リダイレクト）します。IdPが利用者の本人確認（認証）を行い、「認証が済んだ」という結果をSPに伝えると、SPはアクセスを許可します。
ここで押さえたいのは、IdPがSPに渡すのはパスワードそのものではなく「認証が済んだ」という結果だという点です。SAMLではこの認証結果をXML形式のアサーション、OpenID ConnectではJWT（JSON Web Token）形式のIDトークンとして受け渡します。利用者のパスワードはIdPの内側にとどまり、各サービスへは渡りません。
出典・参考資料（2件）
IdPとSPの信頼関係はどう確立されるか
フェデレーションが安全に成り立つのは、IdPとSPがあらかじめ「信頼関係」を結んでいるからです。この信頼関係は、お互いの情報（エンドポイントのURLや公開鍵を含むメタデータ）を事前に交換することで設定します。
認証結果が本物であることは、電子署名で担保されます。SAMLの標準では、利用者のブラウザ経由でアサーションを含むレスポンスをSPに渡す場合、メッセージの改ざんを防ぐためにXML Signatureによる電子署名が必須とされています。
SPはIdPの公開鍵で署名を検証し、「このアサーションは確かに信頼しているIdPが発行したもので、途中で改ざんされていない」と確認できたときだけ、ログインを許可します。パスワードを共有せずに安全な連携が成り立つのは、この署名検証の仕組みがあるためです。
なぜ別ドメイン・別組織をまたげるのか
そもそもなぜフェデレーションという方式が必要なのか、と疑問に思うかもしれません。理由の一つは、Webブラウザのログイン状態を保持する「Cookie」が、異なるドメインの間では共有できない仕組みになっているためです。
自社ドメインで一度ログインしても、そのログイン状態を示すCookieは別ドメインのSaaSには引き継がれません。そこで、ドメインをまたいでも「認証が済んだ」という事実を安全に伝えられるように、電子署名付きのアサーションやIDトークンをやり取りするフェデレーションの仕組みが用いられます。別々に管理されたサービスの間でもSSOを実現できるのは、このためです。
SAML・OpenID Connect・OAuthの役割と違い
フェデレーションを理解するうえで最もつまずきやすいのが、SAML・OpenID Connect・OAuthという3つの規格の違いです。名前が並ぶだけで、役割が取り違えられたりしがちな部分でもあります。ここでは、それぞれの標準仕様の定義にもとづいて、「認証（本人確認）」の規格なのか「認可（権限の委譲）」の規格なのかという軸で整理します。
| 規格 | SAML 2.0 | OpenID Connect | OAuth 2.0 |
|---|---|---|---|
| 標準化団体 | OASIS | OpenID Foundation | IETF |
| 役割 | 認証（＋属性連携） | 認証 | 認可（本人確認ではない） |
| データ形式 | XML（アサーション） | JSON（IDトークン＝JWT） | JSON（アクセストークン） |
| 主な用途 | 企業向けSSO、SaaS連携 | モダンなWeb・モバイル・APIのログイン | サービス間の権限委譲（データアクセスの許可） |
各規格の仕様原文（OASIS／OpenID Foundation／IETF）にもとづく
SAML（XML形式の署名付きアサーション）
SAMLは、OASISという標準化団体が定める、オンラインの事業者間でセキュリティ情報を交換するための枠組みです。IdPとSPという役割を定義し、認証結果を「アサーション」として受け渡します。
アサーションはXML形式で記述され、「この利用者は認証済みである」といった主体に関する主張（statements）を運びます。歴史が長く、企業システムやSaaSのSSOで広く使われている、エンタープライズ向けの規格です。
OpenID Connect（OAuth 2.0上に載る認証レイヤ）
OpenID Connect（OIDC）は、OpenID Foundationが策定する規格で、公式仕様では「OAuth 2.0プロトコルの上に載る、シンプルなアイデンティティ（認証）レイヤ」と定義されています。認可の枠組みであるOAuth 2.0を土台にしつつ、「利用者が誰であるか」を確認する認証の機能を追加したものです。
認証結果は「IDトークン」として受け渡されます。IDトークンはJWT（JSON Web Token）という形式で、利用者が認証された事実に関する情報（クレーム）を含みます。JSONベースで扱いやすく、スマートフォンアプリやAPIとの連携にも向く規格です。
出典・参考資料（1件）
OAuth（認可の枠組みであり、認証ではない）
OAuthは、3つの規格のなかで最も誤解されやすいものです。OAuth 2.0の仕様（RFC 6749）は、その名のとおり「認可（authorization）のフレームワーク」であり、あるアプリケーションが利用者に代わって別のサービスのデータへ限定的にアクセスする権限を得るための枠組みです。発行されるのは、リソースへのアクセス権限を表す「アクセストークン」です。
重要なのは、OAuthは「誰であるか」を確かめる認証の規格ではないという点です。OAuth 2.0の仕様自体も、利用者をどう認証するかは仕様の範囲外だと明記しています。扱うのは「このアプリにこのデータへのアクセスを許可してよいか」という権限の委譲であり、本人確認そのものはOIDCのような認証レイヤが担います。OAuthを認証の仕組みと説明している解説は、この役割を取り違えているため注意が必要です。
出典・参考資料（1件）
フェデレーション以外のSSO実現方式
SSOを実現する方式はフェデレーションだけではありません。IT製品の分野では、一般に次の4つの方式が用いられると整理されています（標準規格が「SSOはこの4つ」と定めているわけではなく、実務で広く使われている分類です）。自社の環境に合う方式を選ぶために、それぞれの仕組みと向き・不向きを押さえておきましょう。
| 方式 | フェデレーション方式 | リバースプロキシ方式 | 代理認証方式 | エージェント方式 |
|---|---|---|---|---|
| 仕組みの概要 | IdPとSPが標準プロトコル（SAML／OIDC）で認証結果を連携する | 利用者とサービスの間に立つプロキシが通信を中継し、認証を代行する | 端末のソフトやブラウザ拡張が、保存したIDとパスワードを代わりに入力する | 各サービスに認証用のモジュール（エージェント）を組み込む |
| 向いているケース | クラウドサービス（SaaS）や外部組織との連携 | 既存システムを改修せずにSSO化したい場合 | 標準プロトコルに対応しない旧来のシステム | 自社運用のシステムを柔軟に連携させたい場合 |
| 注意点 | 連携先が標準プロトコルに対応している必要がある | プロキシに通信が集中し、ネットワーク構成の変更が必要 | 各端末への導入が必要で、認証情報の保管に配慮が要る | 対象ごとの組み込み・改修で工数がかかる |
自社に向く方式はどう選ぶか
方式を選ぶ出発点は、SSO化したい対象が「クラウド中心か、自社運用の旧来システム中心か」です。Microsoft 365やGoogle Workspace、各種SaaSを横断して使う構成であれば、標準プロトコルで連携できるフェデレーション方式が第一候補になります。連携先が増えても、同じ仕組みで追加できる拡張性が利点です。
一方、SAMLやOIDCに対応していない旧来のシステムが多い場合は、既存システムを改修せずに済むリバースプロキシ方式や、ID・パスワードを代理入力する代理認証方式が現実的な選択肢になります。
実際には、クラウドはフェデレーション方式、残る旧来システムは別方式、というように組み合わせて使う構成も珍しくありません。まずは連携対象を棚卸しし、標準プロトコルへの対応状況を確認することが、方式選定の判断材料になります。
フェデレーション導入のメリット・デメリットと具体例
ここからは、フェデレーション方式でSSOを導入したときの利点と注意点を両面から整理し、最後に身近なサービスでのログイン体験を具体的に見ていきます。
導入のメリット
第一の利点は、利用者の利便性です。サービスごとのパスワード入力や使い回しがなくなり、一度のログインで必要なサービスを行き来できます。管理者にとっても、パスワード失念への対応や、退職者のアカウント停止をIdP側でまとめて行える運用のしやすさがあります。
セキュリティ面の利点も大きいといえます。各サービスにパスワードを分散させず、認証をIdPに集約できるため、多要素認証（MFA）やパスワードレス認証といった強固な認証をIdP側で一括してかけられます。認証の強度を一か所で底上げできる点が、セキュリティ統制上の大きな利点になります。
デメリット・注意点とセキュリティ上のリスク
一方で、認証をIdPに集約することは、IdPが単一障害点（SPOF）になりうることを意味します。IdPが停止すれば連携する全サービスにログインできなくなり、IdPのアカウントが乗っ取られれば連携先すべてに影響が及びます。だからこそ、IdP自体に多要素認証を必須化し、アクセス制限やログ監視を併用することが欠かせません。
運用面では、連携先が標準プロトコルに対応している必要があり、対応しないシステムは別の方式で補う手間が生じます。導入・運用のコストや、証明書の有効期限管理・設定ミスへの注意も求められます。設定ミスや確認漏れが不正アクセスの起点になりやすいため、導入後も設定を定期的に点検する体制が欠かせません。メリットとあわせて、これらの運用負荷を踏まえて検討することをおすすめします。
認証をIdPに集約するほど、そのIdP自体をどれだけ強固に守れるかが要になります。多要素認証（MFA）の認証方式ごとの特徴や、自社に合う製品の選び方は、次の記事で比較しています。
具体例：Microsoft 365やGoogle Workspaceでのログイン
イメージをつかむために、身近なサービスで考えてみます。たとえばMicrosoft Entra ID（旧Azure AD）をIdPとして使い、そこにMicrosoft 365やGoogle Workspace、各種SaaSを連携させておくと、利用者は朝に一度Entra IDへログインするだけで、その後はメール・ファイル共有・各SaaSを追加のログインなしで行き来できます。
Google Workspaceも、サードパーティのIdPからのSSOに対応しており、SAMLなどの標準プロトコルで連携できます。そのほかの主要なSaaSの多くも、同様にSAMLでのSSOに対応しています。
こうしたサービスを一つのIdPに集約すれば、利用者の体験は「一度ログインすれば、あとはシームレス」になります。管理者の側も、アカウントと認証を一元的に統制できます。
出典・参考資料（2件）
一括ダウンロードする
SSO・フェデレーションを自社で実現するには
ここまでの内容を踏まえ、自社でフェデレーション方式のSSOを実現する方法を見ていきます。クラウドを横断して使う企業では、SAML 2.0やOpenID Connectに対応し、SSOと多要素認証をまとめて提供する「IDaaS（Identity as a Service）」と呼ばれるクラウド型のID基盤を導入するのが一般的です。
代表的な国産IDaaSを3つ、下の比較表で対応プロトコル・認証方式・料金とともに並べます。そのうち1サービスを、フェデレーション方式を幅広く体現する一例として個別に紹介します。主要なIDaaSを横断して選びたい場合は、後述の比較記事もあわせてご覧ください。
| サービス名 | CloudGate UNO | トラスト・ログイン byGMO | Gluegent Gate |
|---|---|---|---|
| 提供会社 | 株式会社インターナショナルシステムリサーチ | GMOグローバルサイン株式会社 | サイオステクノロジー株式会社 |
| 対応プロトコル（SAML 2.0／OIDC） | SAML 2.0／OpenID Connect | SAML 2.0／OpenID Connect（フォームベース・Basic認証にも対応） | SAML 2.0／OpenID Connect（代理認証にも対応） |
| 対応認証方式（MFA・パスワードレス） | FIDO2／パスキー、生体認証（Windows Hello・Touch ID／Face ID）、OTP（パスワードレスは全プラン・全ユーザー無制限） | パスキー（FIDO2）、OTP（アプリ・メール）、プッシュ通知、顔認証（パスワードレスは有料のSSOプロ） | FIDO／FIDO2外部デバイス認証、生体認証、OTP、ICカード、証明書認証 |
| アクセス制限 | IP制限・デバイス証明書・国／地域・時間帯・ブラウザ制限 | IPアドレス制限・デバイス制限・クライアント認証・ステップアップ認証 | IP制限・端末認証（クライアント証明書）・証明書認証をアクセス制御ルールに組み合わせ |
| 月額費用（税抜） | 400円〜600円／ユーザー | 0円〜（無料プランあり。有料SSOプロ300円〜） | 100円／接続〜（ユーザー単位は250円〜1,000円） |
| 無料トライアル | 30日間 | 要問い合わせ | 要問い合わせ |
| 詳細情報 | 公式資料を見る | サービス詳細を見る | サービス詳細を見る |
※2026年11月時点の各社公式情報による
CloudGate UNO（株式会社インターナショナルシステムリサーチ）
株式会社インターナショナルシステムリサーチ（ISR）が自社開発する、国産のクラウド型ID基盤（IDaaS）です。2008年にGoogle Apps（現Google Workspace）向けのSSOとして始まり、2013年にマルチクラウド対応のCloudGate UNOとして提供を開始しました。SAML 2.0・OpenID Connectに対応し、フェデレーション方式のSSOを標準で実現できます。
認証方式の選択肢が広いのも特徴です。パスキー（FIDO2）によるパスワードレス認証、Windows HelloやTouch ID／Face IDといった端末の生体認証、ワンタイムパスワードなどに対応し、パスキー認証は全プラン・全ユーザーで無制限に利用できます。
FIDOアライアンスに2014年から参画し、2019年にFIDO2準拠のパスワードレス認証を提供開始するなど、認証強化に早くから取り組んできた経緯があります。
アクセス制限は、IPアドレス・デバイス証明書・国や地域・時間帯・ブラウザといった軸で細かく設定できます。料金は月額400円／ユーザー（税抜）からの3プラン構成で、30日間の無料体験も用意されています。導入の前後のサポートは日本語で受けられます。
ここで取り上げたのは代表的な国産IDaaSの一部です。対応プロトコルや料金に加え、選び方の軸や導入事例まで含めて主要なIDaaSを横断で比較したい場合は、次の記事がまとまっています。
まとめ
SSOとフェデレーションは対立する概念ではなく、SSO（一度のログインで複数サービスを使える状態）を実現する方式の一つがフェデレーションである、という包含関係にあります。フェデレーションは、IdPとSPが信頼関係を結び、パスワードそのものではなく署名付きの認証結果（SAMLのアサーションやOIDCのIDトークン）を受け渡すことで、別々に管理されたサービスの間でもログインを連携させる仕組みです。
混同されやすいSAML・OpenID Connect・OAuthは、SAMLとOIDCが「認証」、OAuthが「認可」と役割が分かれます。自社のクラウド環境でSSOを実現するなら、これらの標準プロトコルに対応したIDaaSを選ぶのが近道です。まずは連携したいサービスを棚卸しし、各サービスの資料で対応プロトコルや認証方式を比較してみてください。
一括ダウンロードする
よくある質問（FAQ）
Q. フェデレーションとSSOは同じものですか？
A. フェデレーションとSSOは同じものではなく、SSO（一度のログインで複数サービスを使える状態）を実現する方式の一つがフェデレーションという包含関係にあります。クラウドサービスや別組織のシステムと連携する場面で使われる方式がフェデレーションで、SSOという目的のなかにフェデレーションが含まれると理解すると整理しやすくなります。
Q. SAMLとOpenID Connectは何が違い、どちらを選べばよいですか？
A. SAMLとOpenID Connectはどちらも認証（本人確認）の結果を連携する規格ですが、SAMLはXML形式のアサーション、OpenID ConnectはJSON形式のIDトークン（JWT）で認証結果を受け渡す点が異なります。
歴史が長く企業システムやSaaSのSSOで広く使われているのがSAML、JSONベースでスマートフォンアプリやAPI連携に向くのがOpenID Connectです。多くのIDaaSは両方に対応するため、連携したいサービスがどちらのプロトコルに対応しているかを確認して選ぶのが実務的です。
Q. OAuthはログイン認証に使えますか？
A. OAuthは「認可（権限の委譲）」の枠組みであり、利用者が誰であるかを確かめる認証の規格ではありません。 OAuth 2.0の仕様（RFC 6749）も利用者をどう認証するかは仕様の範囲外だと明記しており、扱うのは「このアプリにこのデータへのアクセスを許可してよいか」という権限の委譲です。
ログイン（本人確認）には、OAuth 2.0の上に認証レイヤを載せたOpenID Connectのような規格を用います。OAuthを認証の仕組みと説明する解説は役割を取り違えているため注意が必要です。
Q. IDaaSとフェデレーションはどのような関係ですか？
A. IDaaS（Identity as a Service）は、フェデレーション方式のSSOをクラウドサービスとして提供するID基盤です。
SAML 2.0やOpenID Connectに対応し、SSOと多要素認証（MFA）をまとめて実現できます。Microsoft 365やGoogle Workspaceなどクラウドを横断して使う企業では、自前で認証基盤を構築せずにIDaaSを導入してフェデレーション方式のSSOを実現するのが一般的です。
Q. フェデレーション以外にどのSSO実現方式があり、どれを選べばよいですか？
A. SSOの実現方式にはフェデレーション方式のほか、リバースプロキシ方式・代理認証方式・エージェント方式があり、SSO化したい対象がクラウド中心か、自社運用の旧来システム中心かで選ぶのが出発点です。SaaSを横断して使う構成なら、標準プロトコル（SAML／OIDC）で連携できるフェデレーション方式が第一候補になります。
標準プロトコルに対応しない旧来システムが多い場合は、既存システムを改修せずに済むリバースプロキシ方式や、ID・パスワードを代理入力する代理認証方式が現実的です。クラウドはフェデレーション、残る旧来システムは別方式、と組み合わせる構成も珍しくありません。
Q. SSO・フェデレーションを導入する際の注意点は何ですか？
A. 最大の注意点は、認証をIdPに集約することで、IdPが単一障害点（SPOF）になりうる点です。IdPが停止すれば連携する全サービスにログインできなくなり、IdPのアカウントが乗っ取られれば連携先すべてに影響が及ぶため、IdP自体への多要素認証の必須化やアクセス制限・ログ監視が欠かせません。
あわせて、連携先が標準プロトコルに対応している必要があることや、証明書の有効期限管理・設定ミスへの備えも求められます。これらの運用負荷を踏まえて検討することをおすすめします。
IDaaS・SSOサービスの料金・資料を一括チェック
MCB FinTechカタログでは、SAML 2.0やOpenID Connectに対応したSSO・IDaaSの最新資料を無料で一括請求できます。対応プロトコル・認証方式・料金を各社の資料でまとめて比較できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
