社内システムと業務で使うクラウドサービスが増えるにつれ、資料や社内の会話で「認証連携」という言葉を目にする機会が増えています。シングルサインオン（SSO）やSAMLといった周辺の用語は聞いたことがあっても、「認証連携とは結局どういう仕組みなのか」を自分の言葉で説明できず、もやもやしている方も多いのではないでしょうか。
認証連携は、複数のシステムやサービスの間で認証の情報を受け渡し、一度のログインでそれらをまとめて使えるようにする仕組みを指します。SSOやフェデレーション、認証基盤といった言葉と重なり合うため、関係を整理しないまま読み進めると、かえって混乱しやすい領域です。
本記事では、認証連携の意味を結論から示したうえで、SSO・フェデレーション・認証基盤との関係、認証情報が受け渡される仕組み、実現方式の種類、SAML・OpenID Connect・OAuthといった標準技術の役割、導入のメリットと注意点、そして自社で検討する際の見極め方までを順に整理します。認証連携の全体像をつかみ、次の一歩へ進むための土台にしてください。
目次
一括ダウンロードする
認証連携とは？
認証連携とは、複数のシステムやサービスの間で認証の情報を受け渡し、利用者が一度ログインすれば、連携先のシステムにも改めてログインし直すことなくアクセスできるようにする仕組みです。英語では「フェデレーション（federation）」と呼ばれ、複数のシステム間で本人であることの情報を受け渡す考え方を指します。
ここでいう「認証」とは、利用者が本人であるかどうかを確認する仕組みのことです。従来はシステムごとにIDとパスワードで個別に認証していましたが、認証連携では、信頼関係を結んだシステム同士が認証の結果を共有します。これにより、利用するサービスの数だけログインを繰り返す必要がなくなります。
出典・参考資料（2件）
認証連携とSSO・フェデレーション・認証基盤の関係
認証連携の話題では、SSO・フェデレーション・認証基盤という言葉が入り混じって使われます。同じ意味なのか、片方がもう片方に含まれるのか、単なる方式の名前なのかが整理されていないと混乱のもとになるため、まず4つの言葉の位置づけを一覧で確認します。
| 用語の関係 | 認証連携（フェデレーション） | シングルサインオン（SSO） | ID管理（IDaaS） | 認証基盤 |
|---|---|---|---|---|
| 何を指すか | 複数のシステム間で認証情報を受け渡す仕組み・考え方 | 一度の認証で複数のサービスを使えるようにする状態・機能 | アカウント（ID）の発行・変更・停止などを一元管理する仕組み。クラウドで提供されるものがIDaaS | SSO・多要素認証・ID管理などを束ねる認証全体の仕組み |
| ほかの用語との関係 | SSOを実現するための土台。英語ではフェデレーションと呼ぶ | 認証連携によって実現される「利用者から見た便利さ」の側面 | 認証連携・SSOと組み合わせて提供されることが多い（実際の製品では両方を兼ねる） | 認証連携・SSOを構成要素として含む、より広い概念 |
※各用語は文脈により指す範囲が前後します。ここでは一般的な整理として示しています。
ひとつ補足すると、「フェデレーション」は認証連携そのものの英語名（広い意味）として使われる一方で、後述の実現方式では標準規格を使う「フェデレーション方式」という、より狭い意味でも使われます。同じ言葉が全体像と一方式の両方を指す場面があるため、文脈で読み分けると混乱を避けられます。
関係を一言でまとめると、認証連携（フェデレーション）という仕組みを使ってSSOという便利さを実現し、それらを多要素認証やID管理とともに束ねたものが認証基盤、という入れ子の構造になります。
標準策定機関であるNISTも、SSOを、1つのアカウントと認証情報で複数のアプリケーションにシームレスにアクセスできる認証プロセスであり、一般にフェデレーションのプロトコルで実装されるもの、と説明しています。SSOとフェデレーションが「便利さ」と「それを支える仕組み」の関係にあることがわかります。
出典・参考資料（1件）
認証連携の仕組み（認証情報の受け渡し）
ここからは、認証連携で認証情報が実際にどう受け渡されるのかを見ていきます。認証連携は、大きく分けて2種類の登場人物によって成り立ちます。
- IdP（Identity Provider／認証する側）：利用者が本人かどうかを確認し、その結果を発行する役割。SSOのログイン画面を提供する認証基盤やIDaaSがこれにあたります。
- SP／RP（Service Provider／Relying Party、サービス側）：IdPが確認した結果を信頼して、利用者にサービスの利用を許可する役割。業務で使う個々のクラウドサービスがこれにあたります。
利用者がサービス（SP）にアクセスすると、SPは認証をIdPに任せます。利用者はIdPでログインし、IdPは「この利用者は確かに本人だと確認した」という情報を、改ざんできない形の「トークン」や「アサーション」と呼ばれるデータにまとめてSPへ渡します。
SPはその内容を検証し、正しければ利用者を受け入れます。この受け渡しがあるため、利用者は2つ目以降のサービスで改めてパスワードを入力する必要がなくなります。
IdPとSPは、あらかじめ信頼関係を結んでいることが前提です。信頼できる相手からの認証結果だからこそ、SPは自前で認証し直さずに受け入れられます。この「信頼関係にもとづく認証情報の受け渡し」が、認証連携の核心です。
認証連携によるSSOの実現方式と比較
認証連携によるSSOには、いくつかの実現方式があります。どの方式を採るかで、対応できるシステムの範囲や導入の手間が変わります。代表的な5つの方式を、仕組み・向いているケース・注意点で比較します。
| 実現方式 | フェデレーション方式 | リバースプロキシ方式 | 代理認証方式 | エージェント方式 | 透過型方式 |
|---|---|---|---|---|---|
| 仕組み | SAMLやOpenID Connectなどの標準規格で、IdPとSPが認証情報を受け渡す | 利用者とWebシステムの間に中継サーバを置き、そこで認証を代行する | 端末に導入したソフトが、各システムのログイン画面にIDとパスワードを自動入力する | 各Webサーバに専用のソフト（エージェント）を組み込み、認証を制御する | ネットワークやOSのログイン情報を引き継ぎ、利用者が意識せず認証を通す |
| 向いているケース | クラウドサービス（SaaS）間のSSO。異なる組織・ドメインをまたぐ連携 | 既存のWebシステムに手を加えずにSSOを後付けしたい場合 | SAMLなどに対応していない古いシステムも含めて広くまとめたい場合 | 自社で管理するオンプレミスのWebシステムが中心の場合 | 社内ネットワークにログイン済みの利用者をそのまま連携させたい場合 |
| 注意点 | 連携先・自社の双方が標準規格に対応している必要があり、非対応の古いシステムはそのままでは連携できない | すべての通信が中継サーバを経由するため、そこが単一障害点や性能上のボトルネックになりやすい | 各システムのIDとパスワードを代理で保持・入力するため、パスワード変更への追従や資格情報の管理に配慮が要る | 対象となる各Webサーバにエージェントの導入・保守が必要で、対応するOSや製品にも制約がある | 社内ネットワークへのログインが前提となり、社外からのアクセスやクラウド単独での利用には向かない |
※方式の呼称や区分は製品・資料により異なる場合があります。
クラウドサービスが中心の環境では、標準規格を使うフェデレーション方式が主流です。一方、標準規格に対応していない社内システムが残る場合は、リバースプロキシ方式や代理認証方式を組み合わせて対応範囲を広げることもあります。自社のシステム構成に、対応していない方式が無いかを確認することが選定の出発点になります。
実際の製品では、これらの方式を個別に選ぶというより、多くのクラウド型のサービス（IDaaS）がフェデレーション方式を基本としながら、対応していないシステム向けに他の方式を補う形で提供しています。そのため、方式そのものよりも「自社が使うシステムに、そのサービスが対応しているか」で見ていくのが現実的です。
SAML・OpenID Connect・OAuthの役割（認証と認可の違い）
フェデレーション方式で使われる標準技術として、SAML・OpenID Connect・OAuthの3つがよく登場します。名前が並ぶと混同しがちですが、それぞれ担う役割が異なります。特に重要なのが「認証」と「認可」の違いです。
- 認証（Authentication）：利用者が「誰であるか（本人か）」を確認すること。
- 認可（Authorization）：確認された利用者に「何のアクセスを許可するか」を決めること。
| 標準技術 | SAML | OpenID Connect（OIDC） | OAuth 2.0 |
|---|---|---|---|
| 策定元 | OASIS | OpenID Foundation | IETF（RFC 6749） |
| 主な役割 | 認証（本人確認などの情報を受け渡す） | 認証（本人確認） | 認可（アクセスの許可） |
| 特徴 | XMLベースで認証などの情報をアサーションとして受け渡す。企業向けSaaSのSSOで広く普及 | OAuth 2.0の上に作られた本人確認のための仕組み。モダンなWeb・モバイルで普及 | アクセスを許可するための枠組み。それ自体は本人確認の仕組みではない |
混同されやすいのがOAuthとOpenID Connectです。OAuthはあくまで「認可」の枠組みであり、標準仕様の表題も「The OAuth 2.0 Authorization Framework（OAuth 2.0 認可フレームワーク）」とされています。
OAuth addresses these issues by introducing an authorization layer and separating the role of the client from that of the resource owner.
出典：RFC 6749 The OAuth 2.0 Authorization Framework｜IETF
その認可の枠組みであるOAuth 2.0の上に、本人確認（認証）の層を追加したものがOpenID Connectです。OpenID Connect自身の仕様が、その位置づけを次のように述べています。
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server（後略）
出典：OpenID Connect Core 1.0｜OpenID Foundation
つまり、OAuth単体は「アクセスの許可」を扱う認可の仕組みで、本人確認そのものは担いません。本人確認まで行いたいときに、その上へ載せるのがOpenID Connectです。
一方SAMLは、XMLをベースに本人確認などの情報を「アサーション」という形で受け渡す標準で、企業向けSaaSのSSOで広く使われています。「認証連携をしたい」ときに関わるのは、主にSAMLとOpenID Connectだと押さえておくと整理しやすくなります。
出典・参考資料（3件）
認証連携を導入するメリット
認証連携を導入すると、利用者・管理者の双方に効果があります。ここでは代表的な3つの観点を整理します。
ログインの手間が減り、利用者の利便性が高まる
一度のログインで複数のサービスを使えるため、利用者はサービスごとにIDとパスワードを入力し直す必要がなくなります。業務で使うSaaSが増えるほど、その効果は顕著です。パスワードを覚えきれずに使い回す、といった行動も起きにくくなります。
セキュリティを強化できる
認証をIdPに集約すると、ログインの入り口を一本化できます。多要素認証やアクセス制御をIdP側でまとめて適用でき、パスワードの使い回しや、退職者アカウントの消し忘れといったリスクを抑えやすくなります。誰がいつどのサービスにログインしたかを一元的に把握できる点も、セキュリティ運用に役立ちます。
ID・パスワード管理の運用負荷を軽減できる
アカウントの発行・停止や棚卸しを認証基盤側で一元管理できるため、システムごとに個別対応していた作業をまとめられます。入退社や異動のたびに複数システムを手作業で設定する負担が減り、情報システム部門の運用負荷を下げられます。
認証連携導入の注意点とリスク・対策
認証連携は便利な一方で、認証を集約するからこその注意点もあります。導入前に、次の3点と対策を押さえておきます。
認証基盤が単一障害点になりやすい
認証を一本化する分、IdPが停止するとすべての連携先にログインできなくなる恐れがあります。対策として、可用性の高い構成（冗長化や信頼性の高いクラウドの利用）を選び、障害時の代替手段をあらかじめ想定しておくことが重要です。サービスを選ぶ際は、提供元が示す稼働率（SLA）や障害対応の体制も確認しておくとよいでしょう。
連携に対応していないシステムが残る
SAMLやOpenID Connectに対応していない古いシステムは、そのままではフェデレーション方式で連携できません。対策として、導入前に自社のシステムが各方式に対応しているかを確認し、対応していないものはリバースプロキシ方式や代理認証方式で補うか、個別対応を検討することが求められます。
認証を集約するほど、侵害されたときの影響が大きくなる
入り口を一本化するということは、その入り口が突破されると連携先すべてに影響が及ぶということでもあります。対策の要は、IdPのログイン自体を多要素認証（MFA）で守ることです。パスワードだけに頼らず、スマートフォンアプリや生体認証などの要素を組み合わせることで、万一パスワードが漏れても不正ログインを防ぎやすくなります。
なお、多要素認証は方式によってフィッシング攻撃などへの強さが異なる点にも留意が必要です。
多要素認証そのものの仕組みや認証の3要素、二段階認証との違い、方式ごとの安全性の違いを基礎から押さえておきたい方は、以下の記事で詳しく解説しています。
MFA（多要素認証）とは？仕組み・3要素と二段階認証との違いをわかりやすく解説
クラウドサービスの利用が当たり前になり、取引先やセキュリティガイドライン、サイバー保険の加入条件などで「MFA（多要素認証）を有効にしてほしい」と求められる場面が増えています。とはいえ、いざMFAという言葉に向き合うと、「二段階認証と何が違…
自社に導入する際の検討・比較の軸
認証連携を実現するサービスを選ぶときは、次の4つの軸で比較すると自社に合うものを見極めやすくなります。いずれも、この後で紹介する比較表の各項目とあわせて確認すると判断しやすくなります。
提供形態はクラウド型かオンプレミス型か
クラウド型（IDaaS）は導入が早く運用の手間が少ない一方、オンプレミス型は自社のポリシーに合わせた細かな作り込みがしやすい傾向があります。利用するシステムがクラウド中心か社内システム中心かによって、適した形態が変わります。料金の課金単位（利用者1人あたりの月額・無料枠の有無）も提供形態とあわせて確認すると、自社の規模に応じたコスト感をつかめます。
既存システムや利用中のSaaSと連携できるか
自社が使っているSaaSや社内システムに、そのサービスが対応しているかを確認しておくことが重要です。SAMLやOpenID Connectへの対応に加え、連携できるサービスがあらかじめ用意されているか（対応済みのアプリ一覧）も、導入のしやすさを左右します。この後の比較表の「対応する認証連携規格」「主な保護対象・連携先」の欄が、その確認の出発点になります。
運用・管理がしやすいか
アカウントの発行・停止やアクセス権の設定を、管理画面から無理なく行えるかも見ておきたいポイントです。多要素認証やアクセス制御など、セキュリティに関わる設定の柔軟さも、日々の運用のしやすさに直結します。無料トライアルがあれば、棚卸しや権限変更など管理者が日常的に行う操作を実際に試すと、画面の使いやすさの差が見えてきます。
導入前後のサポート体制が充実しているか
認証は業務の入り口を担うため、トラブル時に頼れるサポートがあるかは重要です。導入時の設定支援や、日本語での問い合わせ対応、障害時の連絡体制などを、契約前に確認しておくと安心です。
一括ダウンロードする
認証連携・SSOを実現する主なサービス
ここからは、認証連携（SSO）を実現する代表的なサービスを紹介します。いずれもクラウド型のID管理サービス（IDaaS）で、SAMLやOpenID Connectといった標準規格による認証連携に対応しています（対応する規格はサービスにより異なります）。まずは主なサービスの特徴を一覧で比較します。
| サービス名 | CloudGate UNO | Okta（Workforce Identity Cloud） | Microsoft Entra ID | トラスト・ログイン byGMO |
|---|---|---|---|---|
| 提供形態 | クラウド（IDaaS） | クラウド（IDaaS） | クラウド（IDaaS） | クラウド（IDaaS） |
| 対応する認証連携規格 | SAML 2.0 / OpenID Connect | SAML / OpenID Connect | SAML / OpenID Connect | SAML / OpenID Connect |
| SSO | ● | ● | ● | ● |
| 多要素認証（MFA） | ●（全プランでパスキー対応） | ●（Adaptive MFAは上位プラン） | ●（基本MFAは無償版でも可） | ●（パスキー等は有料プラン） |
| 主な保護対象・連携先 | クラウドSaaS全般 （Google Workspace・Microsoft 365・Salesforce・Slack等） ゼロトラスト型SSO・国産 | クラウドSaaS全般 （連携できるアプリ7,000超） 外資・グローバルで広く利用 | Microsoft 365・Azure中心のクラウド／SaaS 条件付きアクセス・Microsoft環境と親和性が高い | クラウドSaaS全般 （連携アプリ数は無制限） 国産・無料プランから開始可 |
| 詳細情報 | 公式資料を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る |
※2026年9月時点の各社公式情報にもとづきます。料金プランや対応機能は変更される場合があるため、最新情報は各社公式サイトでご確認ください。
ここで紹介したサービスは、いずれもSSOや多要素認証（MFA）を備えたID管理サービス（IDaaS）です。対応する認証方式や既存システムとの連携、料金まで含めて主要なIDaaS製品を横並びで比較し、自社に合うものを選びたい場合は、以下の記事もあわせてご覧ください。
IDaaSとは？おすすめ6選を徹底比較｜メリットや選び方・導入事例も紹介
「IDaaSを比較したい」「IDaaSとは何？どのサービスがおすすめ？」 IDaaSとは、ID管理と認証をクラウド上で統合できる仕組みで、複数のクラウドサービスをまとめて管理したい企業に広がっています。 クラウドサービスの利用が増えた近年で…
1. CloudGate UNO（株式会社インターナショナルシステムリサーチ）
株式会社インターナショナルシステムリサーチが提供する、ゼロトラストの考え方にもとづいたシングルサインオンを備えるクラウド型のID管理サービス（IDaaS）です。一度の認証で複数のクラウドサービスにアクセスできる利便性と、必要な権限だけを与える「最小権限」の考え方を組み合わせている点が軸になっています。
パスワードに頼らない認証にも対応し、利用者をパスワード管理の煩わしさから解放するとともに、管理者側のパスワード再発行対応などの負担軽減にもつなげられます。国産サービスで、日本語でのサポートを受けられる点も検討材料になります。
この管理者側の負担が実際にどの程度変わるのかについて、提供元は導入企業の事例を次のように述べています。
導入と同時にパスワードレス認証に切り替えた企業では、IT部門の業務の約20%を占めていたパスワード関連のヘルプデスク業務が「0%」になったという事例があります。
2. Okta（Okta Japan株式会社）
Okta Japan株式会社が提供するOkta（Workforce Identity Cloud）は、世界各国で導入されているクラウド型のID管理サービス（IDaaS）です。数多くのクラウドサービスとの連携があらかじめ用意されており、SSO・多要素認証・アカウントのライフサイクル管理を幅広くカバーします。
SAMLやOpenID Connectといった標準規格に対応し、多様なSaaSを組み合わせて使う環境でも、認証連携を一元的に整えやすいのが強みです。導入・運用に関する情報やノウハウを得やすい点も特徴です。
3. Microsoft Entra ID（日本マイクロソフト株式会社）
Microsoft 365やAzureを利用している企業にとって身近な選択肢が、Microsoft Entra ID（旧Azure Active Directory）です。マイクロソフトのクラウドサービスの認証基盤を担い、SSO・多要素認証・条件付きアクセス・パスワードレス認証を提供します。
Microsoft 365をすでに使っている場合、その認証基盤を土台に他のクラウドサービスへ認証連携を広げやすい点が特徴です。アクセスの条件を細かく制御できる機能も備えており、Microsoft環境を中心とする企業と相性がよいサービスといえます。
4. トラスト・ログイン byGMO（GMOグローバルサイン株式会社）
GMOグローバルサイン株式会社が提供するトラスト・ログイン byGMOは、シングルサインオン・ID管理・アクセス制限・ログの各機能を中核とした、国産のクラウド型ID管理サービス（IDaaS）です。基本機能を無料プランから使い始められる点が特徴です。
電子認証局を運営するGMOグローバルサインのセキュリティ事業の一環として提供されており、まず小さく始めて必要に応じて機能を広げたい企業に向いています。国産サービスとして日本語のサポートを受けられる点も検討材料になります。
まとめ
認証連携とは、複数のシステム間で認証情報を受け渡し、一度のログインで複数のサービスを使えるようにする仕組みです。利用者から見た便利さがSSO、それを支える仕組みが認証連携（フェデレーション）、さらに多要素認証やID管理まで含めて束ねたものが認証基盤にあたります。それぞれが段階的に組み合わさった関係だと捉えておくと、用語に迷いにくくなります。
実現方式にはフェデレーション方式をはじめ複数の選択肢があり、標準技術ではSAMLとOpenID Connectが認証を、OAuthが認可を担います。導入にあたっては、単一障害点や連携できないシステムへの備えとして、多要素認証の併用や対応範囲の確認が欠かせません。自社のシステム構成と運用体制に合ったサービスを見極める材料として、本記事を役立ててください。
一括ダウンロードする
よくある質問（FAQ）
Q. 認証連携とは何ですか？
A. 認証連携とは、複数のシステムやサービスの間で認証情報を受け渡し、一度ログインすれば連携先のサービスにも改めてログインし直すことなくアクセスできるようにする仕組みです。英語ではフェデレーション（federation）と呼ばれ、信頼関係を結んだシステム同士が認証の結果を共有することで、利用するサービスの数だけログインを繰り返す必要をなくします。
Q. 認証連携とSSO（シングルサインオン）は同じものですか？
A. 認証連携とSSOは同じものではなく、認証連携（フェデレーション）という仕組みによって、SSO＝一度のログインで複数のサービスを使える便利さが実現される関係にあります。認証連携が「それを支える仕組み」、SSOが「利用者から見た便利さ」の側面にあたります。さらに多要素認証やID管理まで加えて束ねたものが認証基盤で、認証連携・SSOはその構成要素という位置づけです。
Q. 認証連携・SSOとID管理（IDaaS）は何が違いますか？
A. 認証連携・SSOが「認証の結果をシステム間で受け渡し、ログインを一度で済ませる仕組み」であるのに対し、ID管理はアカウントの発行・変更・停止といったIDのライフサイクル全体を管理する仕組みで、担う役割が異なります。実際のクラウド型ID管理サービス（IDaaS）では、この両方をあわせて提供することが一般的です。
Q. SAMLとOpenID Connectは何が違いますか？
A. SAMLとOpenID Connectは、どちらも認証連携で本人確認の情報を受け渡すための標準規格ですが、SAMLはXMLをベースに企業向けSaaSのSSOで広く普及しているのに対し、OpenID ConnectはOAuth 2.0を土台にしたモダンなWeb・モバイル向けの仕組みである点が主な違いです。
なお、名前の似たOAuth 2.0は本人確認（認証）ではなくアクセスの許可（認可）を担う枠組みで、役割が異なる点に注意が必要です。
Q. 認証連携はすべてのシステムで使えますか？
A. 認証連携はすべてのシステムで使えるとは限らず、SAMLやOpenID Connectに対応していない古いシステムは、そのままではフェデレーション方式で連携できない場合があります。対策として、導入前に自社のシステムが各方式に対応しているかを確認し、対応していないものはリバースプロキシ方式や代理認証方式で補うか、個別対応を検討することが求められます。
Q. 中小企業や小規模な組織でも認証連携は導入できますか？
A. 認証連携は中小企業や小規模な組織でも導入でき、導入が早く運用の手間が少ないクラウド型（IDaaS）を選べば、小さく始めて必要に応じて機能を広げられます。基本機能を無料から使い始められるサービスもあり、利用するシステムがクラウド中心か社内システム中心かに応じて、提供形態（クラウド型／オンプレミス型）や既存SaaSとの連携可否を比較して選ぶとよいでしょう。
多要素認証・認証連携サービスの料金・資料を一括チェック
MCB FinTechカタログでは、認証連携やSSO、多要素認証に対応した法人向けサービスの最新資料を無料で一括請求できます。対応する認証方式や連携できるサービス、料金をまとめて比較できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
