サービス比較の記事一覧

AIで顧客対応・サポート業務を自動化したい

サービス比較の記事一覧

AIで顧客対応・サポート業務を自動化したい

シングルサインオン(SSO)の認証方式6種類|仕組み・メリットと自社に合う選び方

シングルサインオン(SSO)の認証方式6種類のサムネイル画像
IDaaS(ID管理システム)比較表(2026年版)のプレビュー

主要6サービスの料金・機能を無料で一覧比較

IDaaS(ID管理システム)比較表(2026年版)

複数のクラウドサービスや社内システムを使い分けるうちに、ID・パスワードの管理負担が膨らみ、シングルサインオン(SSO)の導入を検討し始めた企業は少なくありません。SSOの導入を調べ始めると、「SSOにはいくつかの方式がある」という説明に行き当たります。

フェデレーション、代理認証、リバースプロキシといった方式の名前は目にするものの、それぞれが何を指し、どう違うのかは整理しにくいものです。方式ごとに向いている環境が異なるため、自社のシステム構成に合わない方式を選ぶと、導入後に連携できないシステムが出てくることもあります。

本記事では、SSOの認証方式を6種類に整理し、それぞれの仕組みとメリット・デメリットを解説します。全方式を1枚で対照できる比較表と、自社の環境に合う方式の選び方もあわせて示します。方式の違いを理解し、自社に適したSSOを検討するための材料としてご活用ください。

IDaaS(ID管理システム)の関連サービス資料
PR
料金や機能は各社の資料でまとめて比較できます 【無料】IDaaS(ID管理システム)の資料を
一括ダウンロードする
本セクションにはプロモーションが含まれており、表示順は当社独自の基準や提携状況に基づいています。

シングルサインオン(SSO)とは

シングルサインオン(SSO)とは、一度の認証で複数のシステムやクラウドサービスへログインできる仕組みです。サービスごとに個別のID・パスワードを入力する必要がなくなり、ユーザーの手間とパスワードの管理負担を減らせます。管理者側も、アカウントを一元管理でき、退職者のアクセス停止やパスワードポリシーの統一を一箇所で行えます。

SSOを実現する技術的な手段は1つではなく、認証をどこで・どのように代行するかによって複数の方式に分かれます。どの方式が使えるかは、連携したいシステムがクラウドか社内システムか、標準規格に対応しているかといった条件によって変わります。方式の違いを理解することが、自社に合うSSOを選ぶ出発点になります。

認証と認可の違い

SSOの方式を理解するうえで、「認証」と「認可」の区別を押さえておくと、各方式が何を受け渡しているのかが掴みやすくなります。認証(Authentication)は「利用者が本人であることを確かめる」処理で、認可(Authorization)は「確かめた利用者にどのサービス・データへのアクセスを許すか」を決める処理です。

SSOは主に認証の部分を一元化する仕組みです。後述するフェデレーション方式では、認証を担う側が「この利用者は本人だと確認した」という情報(認証結果)を、サービス側へ受け渡します。パスワードそのものではなく、認証の事実を受け渡す点が、方式ごとの安全性の違いにつながります。

SSOの認証方式は6種類と各方式の仕組み

SSOの認証方式は、代表的なもので次の6種類に整理できます。まず全体像として、どのような方式があるのかを一覧で確認します。

  1. フェデレーション方式(SAML・OpenID Connect)
  2. 代理認証(フォームベース)方式
  3. リバースプロキシ方式
  4. エージェント方式
  5. 透過型方式
  6. ケルベロス方式

この6種類は、「誰が・どこで認証を代行し、認証情報をどう受け渡すか」という切り口で分けた分類です。1番目のフェデレーション方式は、SAMLとOpenID Connectという2つの規格を含みます。5番目の透過型方式は「利用者が操作せずに認証が通る」という利用者体験に着目した分類で、6番目のケルベロス方式はチケットを用いる認証技術そのものを指すため、両者は切り口が異なります。

ここからは、各方式が「誰が認証を代行し、どこで認証情報を受け渡すのか」という仕組みと、それぞれのメリット・デメリットを順に解説します。

フェデレーション方式(SAML・OpenID Connect)

フェデレーション方式は、認証を担うIdP(Identity Provider:認証を行い利用者情報を管理する側)と、サービスを提供するSP(Service Provider:利用者にサービスを提供する側)が、標準規格にそって認証結果をやり取りする方式です。受け渡しの流れは次のとおりです。

  1. 利用者がSPにアクセスすると、認証のためIdPへ案内される
  2. 利用者はIdPでログイン(認証)する
  3. IdPは「本人だと確認した」という認証結果のデータ(アサーション/IDトークン)をSPへ渡す
  4. SPはそのデータを信頼してログインを許可する
フェデレーション方式で認証結果を受け渡す流れの図解。STEP1 利用者がSPにアクセスすると認証のためIdPへ案内される、STEP2 利用者がIdPでログインする、STEP3 IdPが本人と確認した認証結果(アサーションまたはIDトークン)をSPへ渡す、STEP4 SPがそのデータを信頼してログインを許可する。SPへはパスワードそのものではなく認証の結果だけを受け渡す。

代表的な規格がSAML(Security Assertion Markup Language)とOpenID Connect(OIDC)です。SAML 2.0は、認証・属性・認可に関する情報をXML形式で記述し、それを受け渡すプロトコルを定めた規格で、認証結果は「アサーション」と呼ばれるデータとしてSPへ渡されます。

OpenID Connectは、OAuth 2.0というプロトコルの上に認証の層を加えた規格で、認証結果を「IDトークン」という形で受け渡します。いずれの規格も、SPへパスワードそのものを渡さず認証の結果だけを受け渡すため、各サービスにパスワードを預けずに済む点が特徴です。

出典・参考資料(2件)

パスワードをサービス側に渡さず、認証の結果だけを受け渡すため安全性が高く、SAMLやOpenID Connectに対応するクラウドサービスの多くと連携できます。クラウド中心の環境と相性の良い方式です。ただし連携先がこれらの規格に対応していることが前提で、規格に対応しない社内システムやレガシーなアプリケーションには適用できません。

代理認証(フォームベース)方式

代理認証方式は、各サービスのログイン画面(フォーム)に、SSOツールが利用者に代わってID・パスワードを自動入力してログインする方式です。フォームベース方式とも呼ばれます。利用者はSSOツールに一度ログインすれば、あとはツールが各サービスへIDとパスワードを代理で送信します。

既存のログイン画面をそのまま使うため、連携先が標準規格に対応していなくても適用でき、対応アプリを選びません。古い社内システムや規格非対応のサービスにもSSOを広げられる点が強みです。

一方で、SSOツール側がID・パスワードを保持・送信するため、認証結果だけを受け渡すフェデレーション方式に比べるとパスワードの管理に注意が必要です。連携先のログイン画面の仕様が変わると、自動入力が動かなくなることもあります。

リバースプロキシ方式

リバースプロキシ方式は、利用者とサービスの間にリバースプロキシ(通信を中継するサーバー)を置き、プロキシが認証を代行する方式です。利用者からの通信はいったんプロキシを経由し、プロキシで認証を確認してからサービスへ中継されます。

前述の代理認証がサービスごとのログイン画面にID・パスワードを代わりに入力するのに対し、リバースプロキシ方式は通信経路そのものを中継し、プロキシを通る段階で認証を確認する点が異なります。

既存のアプリケーションに手を加えずに導入でき、認証をプロキシに集約できるのが利点です。反面、すべての通信がプロキシを経由するため、ここが停止すると全体がつながらなくなる単一障害点になりやすい点に注意が要ります。適用範囲もプロキシを経由できる通信に限られます。

エージェント方式

エージェント方式は、SSOの対象となる各Webサーバーに「エージェント」と呼ばれる専用のソフトウェア(モジュール)を組み込み、アクセスのたびにエージェントが認証状態を確認する方式です。認証サーバーと連携し、認証済みかどうかをエージェントが判定します。

通信経路を1箇所に集約しないため、特定のサーバーへの負荷集中が起きにくいのが特徴で、既存のネットワーク構成を大きく変えずに導入できます。その代わり、対象サーバーごとにエージェントを導入・更新し続ける運用の手間がかかり、エージェントが対応しないサーバーには使えません。

透過型方式

透過型方式は、利用者が特別な操作をしなくても、通信を監視して認証を通す方式です。たとえば社内のWindows環境では、すでにパソコンへログインしている利用者の認証情報を使い、裏側で自動的に各サービスの認証を済ませます。利用者から見ると、ログイン操作を意識せずにサービスを使える状態になります。

利用者の操作や画面の見え方を変えずにSSOを実現でき、ログインを意識させない利便性が最大の利点です。半面、通信経路や利用環境に依存し、適用できる環境が限られます。社内ネットワークやActive Directoryのような特定の基盤を前提とする場合が多い方式です。

ケルベロス方式

ケルベロス(Kerberos)方式は、KDC(Key Distribution Center:鍵配布センター)と呼ばれる認証サービスがチケットを発行し、そのチケットを使って各サービスの認証を通す方式です。

チケットを受け渡す流れは次のとおりです。

  1. 利用者がKDCで認証を受け、「チケット発行用のチケット(TGT)」を受け取る
  2. 各サービスを使うとき、TGTを使ってそのサービス用のチケットをKDCから取得する
  3. サービスはチケットを確認し、認証済みとして利用を許可する
ケルベロス方式でチケットを受け渡す流れの図解。KDC(鍵配布センター)がチケットを発行する。STEP1 利用者がKDCで認証を受けチケット発行用のチケット(TGT)を受け取る、STEP2 利用者がTGTを使ってそのサービス用のチケットをKDCから取得する、STEP3 サービスがチケットを確認し認証済みとして利用を許可する。

ケルベロスは、Windows Active Directoryが標準で用いる認証プロトコルで、前述の透過型方式を実現する技術の一つでもあります。

社内のWindows環境でチケットを用いた安全な認証を実現できる点が強みです。一方で、クラウドサービスやWindows以外の環境との連携には制約があり、社内環境を前提とする場面が中心になります。

出典・参考資料(1件)

6つの認証方式を比較

以下は、ここまで解説した6つの認証方式の比較表です。仕組みの概要・主な対象システム・メリット・デメリットを横に並べ、方式ごとの違いを対照できるように整理しました。

← 横にスクロールできます →
認証方式フェデレーション方式(SAML/OIDC)代理認証(フォームベース)方式リバースプロキシ方式エージェント方式透過型方式ケルベロス方式
仕組みの概要IdPとSPが標準規格で認証結果(アサーション/IDトークン)を受け渡す。パスワードはSPに渡さないログイン画面にID・パスワードを代理で自動入力する利用者とサービスの間に置いた中継サーバーで認証を代行する各Webサーバーに専用ソフトを組み込み認証状態を確認する通信を監視し、ログイン済みの認証情報で裏側で認証を通すKDCがチケットを発行し、チケットで各サービスの認証を通す
主な対象システムSAML/OIDC対応のクラウドサービス規格非対応のWebアプリ・レガシーシステムも可既存のWebアプリ(改修不要)エージェント導入可能なWebサーバー社内ネットワーク・Active Directory環境Windows Active Directory環境
メリット標準規格で安全に連携/パスワードを各サービスに渡さない対応アプリを選ばず広く適用できるアプリ側の改修なしで認証を集約できる通信を1箇所に集約せず負荷集中が起きにくい利用者の操作を変えずに使え利便性が高い社内Windows環境で普及し安全な認証を実現
デメリット連携先が規格に対応している必要があるパスワードを保持・送信する/画面変更で動かなくなることがあるプロキシに負荷・通信が集中し単一障害点になりうる対象サーバーごとに導入・更新の手間がかかる通信経路・利用環境に依存し適用範囲が限られるクラウド・非Windows環境との連携に制約がある

※上記は各方式の一般的な特徴の傾向です。実際の対応範囲や挙動は、採用するサービス・製品によって異なります。

料金や機能は各社の資料でまとめて比較できます 【無料】IDaaS(ID管理システム)の資料を
一括ダウンロードする

自社環境に合うSSO方式の選び方

SSOの方式は、連携したいシステムがクラウド中心か社内システムか、既存のアプリケーションを改修できるか、Active Directoryを運用しているかといった自社の環境によって、向き不向きが分かれます。ここでは、代表的な環境ごとに適合しやすい方式を整理します。

← 横にスクロールできます →
自社の環境クラウドサービスが中心規格に対応しないレガシーな社内Webアプリがある既存アプリを改修せずに認証を集約したい既存のWebサーバーに専用ソフトを導入でき、通信を1箇所に集約したくないActive Directoryを運用する社内Windows環境
適合しやすい方式フェデレーション方式(SAML/OIDC)代理認証方式リバースプロキシ方式エージェント方式ケルベロス方式・透過型方式
理由主要なクラウドサービスがSAML・OpenID Connectに対応しており、パスワードを各サービスに渡さず安全に連携できるためログイン画面へのID・パスワードの代理入力で、標準規格に対応していないアプリにも適用でき、対応アプリを選ばないため利用者とサービスの間の中継サーバーで認証を代行するため、アプリケーション側の改修なしに導入できるため各Webサーバーにエージェントを組み込む構成で、通信経路を1箇所に集約せず負荷集中を避けられるためActive Directoryの認証基盤を活かし、ログイン済みの端末から操作を意識せずに認証を通せるため

※環境と方式の対応は一般的な傾向です。実際には複数の方式を組み合わせて使う場合もあります。

ただし、クラウドサービスと社内システムが混在する環境では、1つの方式だけですべてのシステムをカバーできないことがあります。

複数方式に対応するSSO/IDaaSで実現する

複数の認証方式に対応したSSO/IDaaS(ID管理をクラウドで提供するサービス)を導入すれば、方式の異なるシステムをまとめて一元的に認証でき、方式の使い分けをサービス側に任せられます。ここでは、複数方式に対応するサービスを紹介します。

以下はご紹介するSSO/IDaaSの比較表です。

← 横にスクロールできます →
サービス名CloudGate UNOGMOトラスト・ログイン
提供会社株式会社インターナショナルシステムリサーチGMOグローバルサイン株式会社
対応する認証方式SAML 2.0・OpenID Connect・フォームベース認証フォームベース認証・SAML認証・Basic認証(OIDC認証は上位プラン・有料オプション)
多要素認証・パスワードレスFIDO2/パスキーのパスワードレス認証に対応(全プラン・全ユーザー無制限)。生体認証・OTPも利用可多要素認証に対応(OTP・デバイス制限・証明書認証など)
SSO連携できるサービスGoogle Workspace・Microsoft 365・Salesforce・Slackなど主要クラウドに対応Google Workspace・サイボウズなど主要SaaSに対応(連携アプリ数は無制限)
月額費用400円〜600円/ユーザー(税抜)無料プランあり/有料は290円〜500円/ID・月(税抜、最小30ID)
無料トライアル30日間14日間
詳細情報公式資料を見るサービス詳細を見る

1. CloudGate UNO(株式会社インターナショナルシステムリサーチ)

CloudGate UNOの公式サイト

CloudGate UNOは、株式会社インターナショナルシステムリサーチが自社開発するクラウド型のID管理プラットフォームで、SSO・多要素認証・アクセス制限・ID管理を統合して提供しています。IdPとして、SAML 2.0・OpenID Connect・フォームベース認証の各方式でクラウドサービスとSSO連携でき、規格に対応したサービスから既存のログイン画面を使うサービスまで幅広くカバーします。

アクセス制限を「端末・場所・時間」の3つの軸で設定でき、私用端末からのアクセス禁止や特定拠点・時間帯への限定ができる点が特徴です。認証にはパスキー(FIDO2)によるパスワードレス認証を採用し、フィッシング攻撃への耐性を高めています。月額費用はStandard Plusで1ユーザーあたり400円(税抜)からで、30日間の無料トライアルも用意されています(2026年9月時点の公式情報による)。

記事の冒頭で触れたパスワードの管理負担について、パスワードレス認証への切り替えが管理業務にどう影響するかを、提供元の株式会社インターナショナルシステムリサーチは独自インタビューで次のように述べています。

平澤氏
株式会社インターナショナルシステムリサーチ 営業本部マーケティング部
平澤氏
独自インタビューより

導入と同時にパスワードレス認証に切り替えた企業では、IT部門の業務の約20%を占めていたパスワード関連のヘルプデスク業務が「0%」になったという事例があります。

2. GMOトラスト・ログイン(GMOグローバルサイン株式会社)

GMOトラスト・ログインの公式サイト

GMOトラスト・ログイン(TrustLogin by GMO)は、GMOグローバルサイン株式会社が提供するクラウド型のID管理サービス(IDaaS)です。認証方式はフォームベース認証・SAML認証・Basic認証に対応し、OIDC認証は上位プラン・有料オプションで利用できます。

Google Workspaceやサイボウズなど主要なSaaSへのシングルサインオンとID・パスワードの一元管理を実現します。

SSO連携できるアプリ数に上限がなく、連携数に応じた段階課金がない料金設計も特徴です。SSO機能を中心とした基本プランに加え、有料オプションや上位プランでOIDC認証・多要素認証・SaaS利用状況の可視化などを追加できます。

料金は無料のSSOプランのほか、有料プランが1IDあたり月額290円〜(税抜、最小30ID)用意されており、14日間の無料体験もあります(2026年8月時点の公式情報による。無料プランの範囲やOIDC対応・各プランの価格は最新の公式情報をご確認ください)。

ここで紹介した2サービスのほかにも、複数の方式に対応するSSO/IDaaSは複数あります。ID・パスワードの保管や社内での共有、定期的な棚卸しまで含めて管理を見直したい場合は、SSO連携にも対応した法人向けツールを横断で比較した以下の記事が、選び方や機能の確認に役立ちます。

まとめ

SSOの認証方式は、フェデレーション方式(SAML・OpenID Connect)・代理認証方式・リバースプロキシ方式・エージェント方式・透過型方式・ケルベロス方式の6種類に整理できます。

クラウドサービス中心ならフェデレーション方式、規格に対応しないレガシーシステムがあれば代理認証方式やリバースプロキシ方式、Active Directory運用ならケルベロス方式や透過型方式が適合しやすいなど、方式ごとに向いている環境が異なります。

自社の環境にクラウドと社内システムが混在する場合は、複数方式に対応したSSO/IDaaSを選ぶことで、方式の使い分けをサービス側に任せながら認証を一元化できます。方式の違いを踏まえ、自社のシステム構成に合うサービスの資料を取り寄せて比較検討を進めてみてください。

料金や機能は各社の資料でまとめて比較できます 【無料】IDaaS(ID管理システム)の資料を
一括ダウンロードする

よくある質問(FAQ)

Q. SSOの認証方式とは何ですか?

A. SSOの認証方式とは、シングルサインオン(SSO)を「どこで・どのように認証を代行するか」で分類したもので、代表的にはフェデレーション方式・代理認証方式・リバースプロキシ方式・エージェント方式・透過型方式・ケルベロス方式の6種類があります。方式ごとに、認証を代行する場所や認証情報の受け渡し方が異なります。

どの方式が使えるかは、連携したいシステムがクラウドか社内システムか、標準規格に対応しているかによって変わるため、自社の環境に合わせて選ぶことが出発点になります。

Q. SSOの認証方式で最もセキュリティが高いのはどれですか?

A. SSOの認証方式のうち、パスワードそのものを各サービスに渡さないという点で安全性が高いとされるのはフェデレーション方式(SAML・OpenID Connect)です。認証結果だけをアサーションやIDトークンとしてサービス側へ受け渡すため、各サービスにパスワードを預けずに済みます。

ただし、どの方式であっても安全性は運用の仕方に大きく左右されます。方式の違いだけで安全性が決まるわけではなく、多要素認証(MFA)の併用や、推測されにくいパスワードの運用とあわせて考えることが重要です。

Q. SSOのSAML認証とOpenID Connectは何が違いますか?

A. SAMLとOpenID Connectはどちらもフェデレーション方式で使われる標準規格ですが、SAMLは認証結果をXML形式の「アサーション」で受け渡し、OpenID ConnectはOAuth 2.0というプロトコルの上にIDトークンの層を加えて認証結果を受け渡す点が異なります。

SAMLは企業向けのSaaSやシステム間連携で広く使われてきた実績があり、OpenID ConnectはスマートフォンアプリやWebサービスとの連携で採用が進んでいます。いずれもパスワードをサービス側に渡さずに認証結果だけを受け渡す点は共通しており、連携したいサービスがどちらの規格に対応しているかで選ぶことになります。

Q. 既存の社内システムを改修できない場合、SSOはどの方式で実現できますか?

A. アプリケーションに手を加えられない場合は、リバースプロキシ方式か代理認証(フォームベース)方式が適合しやすいです。リバースプロキシ方式は利用者とサービスの間に置いた中継サーバーで認証を代行し、代理認証方式は既存のログイン画面にID・パスワードを自動入力するため、いずれもアプリ側の改修なしでSSOを適用できます。

標準規格(SAML・OpenID Connect)に対応していないレガシーな社内Webアプリにもこれらの方式なら広げられます。ただし、リバースプロキシ方式はすべての通信が中継サーバーを経由するため単一障害点になりうる点、代理認証方式はログイン画面の仕様変更で自動入力が動かなくなる場合がある点に留意が必要です。

Q. クラウドサービスと社内システムの両方をSSOでまとめられますか?

A. クラウドと社内システムが混在する環境では1つの方式だけで全体をカバーしきれないことが多く、複数の認証方式に対応したSSO/IDaaSを使えば、両方をまとめて一元的に認証できます。たとえばクラウドサービスはフェデレーション方式、規格非対応の社内アプリは代理認証方式、というように方式の使い分けをサービス側に任せられます。

自社で方式ごとに個別の仕組みを構築・運用するより管理の手間を抑えられるため、システム構成が多様な企業ほど複数方式対応のサービスが選択肢になります。

Q. SSOを導入する際にセキュリティ上の注意点はありますか?

A. SSOは認証を一元化する仕組みのため、その認証情報が突破されると連携するすべてのサービスに影響が及ぶ点と、認証基盤が停止すると各サービスにログインできなくなる点に注意が必要です。入口が1つに集約される分、その入口の防御と可用性が全体のセキュリティを左右します。

対策としては、多要素認証(MFA)やパスワードレス認証を併用して認証の突破自体を防ぐこと、認証基盤を冗長化して停止による影響を抑えることが挙げられます。方式を選ぶ際は、こうした多要素認証や可用性への対応状況もあわせて確認するとよいでしょう。

SSO・ID管理サービスの料金・資料を一括チェック

MCB FinTechカタログでは、シングルサインオンやID管理に対応したサービスの最新資料を無料で一括請求できます。対応する認証方式や料金、多要素認証の有無をまとめて比較できます。

料金や機能は各社の資料でまとめて比較できます 【無料】IDaaS(ID管理システム)の資料を
一括ダウンロードする

MCB FinTechカタログに掲載しませんか?

MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。

監修者

マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト

松嶋真倫

都市銀行にて金融実務を経験後、暗号資産関連スタートアップの創業期に参画し、市場分析・業界調査に従事。2018年にマネックスグループ入社。以降、ビットコインをはじめとするデジタルアセットからマクロ経済環境まで、金融市場を横断した調査・分析および情報発信を担う。FinTech・次世代金融領域のリサーチ統括、各種レポートや書籍の執筆、日本経済新聞など国内主要メディアへのコメント・寄稿、イベント登壇などを行う。2021年3月より現職。
記事内でご紹介している製品・サービスは監修者が選定したものではなく、編集部が独自に選定したものです。
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。

関連記事

新着記事