社内で使うクラウドサービスのシングルサインオン（SSO）設定画面や、ベンダーの資料を開くと、「SAML認証」という言葉が繰り返し出てきます。設定を進める前に、これが何を指す言葉なのか、そしてログインの瞬間に裏で何が動いているのかを正確につかんでおきたい場面は多いものです。
SAML認証は、複数のサービスへのログインを1つにまとめるSSOを支える仕組みの一つです。ただ、「SAML＝SSO」と雑にとらえたり、OAuthとの違いが曖昧なまま製品選定に進んだりすると、自社に合わない方式を選んでしまうおそれもあります。
本記事では、SAML認証とは何かという定義から、IdP（認証する側）とSP（使いたいサービス側）の間で認証情報がやり取りされる認証の流れ、メリット・デメリット、OAuth・OpenID Connect・LDAPとの違い、導入時の注意点までを解説します。あわせて、SAML認証に対応したSSO・IDaaS（クラウド型のID管理サービス）も紹介します。
一括ダウンロードする
目次
一括ダウンロードする
SAML認証とは？
SAML認証とは、XMLというデータ記述形式をベースにした標準規格「SAML（Security Assertion Markup Language：セキュリティアサーションマークアップ言語）」を使い、サービスをまたいで認証情報を安全にやり取りする仕組みです。この規格は、認証や属性といった「セキュリティに関する言明（アサーション）」をXMLで表現し、サービス間で受け渡すための取り決めを定めています。
規格の原文では、SAMLは次のように定義されています。
Security Assertion Markup Language (SAML)
出典：Glossary for the OASIS Security Assertion Markup Language (SAML) V2.0｜OASIS
The set of specifications describing security assertions that are encoded in XML, profiles for attaching the assertions to various protocols and frameworks, the request/response protocol used to obtain the assertions, and bindings of this protocol to various transfer protocols (for example, SOAP and HTTP).
この定義は、SAMLが、XMLで表したセキュリティのアサーションと、それを各種プロトコルに載せるためのプロファイルを定めた仕様群だということを示しています。あわせて、アサーションを取得するためのリクエスト/レスポンス手順や、SOAPやHTTPへの載せ方までを含みます。
XMLベースの標準規格（OASISが2005年に標準化したSAML 2.0）
SAMLは、特定の企業の独自仕様ではなく、業界団体が策定した公開された標準規格です。策定したのは、国際的な標準化団体であるOASIS（Organization for the Advancement of Structured Information Standards）で、現在広く使われている「SAML 2.0」は2005年3月15日にOASIS標準として承認されました。
標準規格であるため、規格に準拠したサービスどうしであれば、提供元が異なっていても認証情報を受け渡せます。この相互運用性が、多数のクラウドサービスを横断するSSOの土台になっています。SAML 2.0はこの承認以降、仕様としては安定しており、長く使われてきた枯れた規格でもあります。
SAML認証とSSOの関係
SAMLとSSOは混同されがちですが、両者は同じものではありません。SSO（シングルサインオン）は「一度の認証で複数のサービスにログインできる状態」を指す考え方であり、SAMLはその状態を実現するための手段の一つです。
SSOを実現する方式にはほかにもエージェント方式や代理認証方式などがあり、SAMLはそのうちの「フェデレーション方式（信頼関係を結んだサービス間で認証情報を共有する方式）」にあたります。
SAML規格の原文でも、SSOはSAMLの「プロファイル（使い方の定義）」の一つとして位置づけられています。「SAML＝SSO」ではなく、「SAMLはSSOを実現する枠組みの一つ」と理解するのが正確です。この区別を押さえておくと、後述するOAuthなど他の規格との違いも整理しやすくなります。
SAML認証の仕組みと認証の流れ（SP Initiated／IdP Initiated）
ここからは、ログインの瞬間に裏で何が動いているのかを具体的に見ていきます。SAML認証の流れには、どちら側からログインを始めるかによって「SP Initiated方式」と「IdP Initiated方式」の2つがあります。いずれもOASISのWebブラウザSSOプロファイルで定義された手順にもとづきます。
まず、2つの方式でユーザー・サービス（SP）・認証基盤（IdP）の間を認証要求と応答がどう行き来するかを、全体像で見ておきましょう。
SP Initiated方式の認証の流れ
SP Initiated方式は、利用者が使いたいサービス（SP：サービスプロバイダー）のページにアクセスするところから始まる、もっとも一般的な流れです。規格では、次の6ステップで定義されています。
- SPへアクセス：利用者が、使いたいサービス（SP）にアクセスする
- IdPの特定：SPが、認証を任せる相手であるIdP（アイデンティティプロバイダー＝認証する側）を特定する（あらかじめ連携先のIdPを登録しておくことで、どのIdPに認証を求めるかが決まる）
- 認証リクエストの発行：SPがIdPに対し、認証を求めるリクエスト（<AuthnRequest>）を送る
- 利用者の認証：IdPが、利用者本人（principal）をログイン画面などで認証する
- 応答の返送：IdPがSPに対し、認証結果をまとめた応答（<Response>。少なくとも認証アサーション＝認証結果の言明を含む。詳しくは後述）を返す
- アクセスの許可・拒否：SPが応答の内容を検証し、問題がなければアクセスを許可する
利用者から見ると、サービスにアクセスしたら認証画面に移り、認証が済むと元のサービスに戻ってログインできている、という体験になります。この裏で、SPとIdPがリクエストと応答をやり取りしているわけです。
IdP Initiated方式の認証の流れ
IdP Initiated方式は、利用者が先にIdP（社内ポータルなど認証する側）にログインし、そこから使いたいサービスを選ぶ流れです。規格では、SP Initiatedの前半（上記ステップ1〜4）を省き、IdPがステップ5から始めてSPへ応答を送るものとして定義されています。以下では、この方式の流れを新たに1から数え直して示します。
- IdPへログイン：利用者が、社内ポータルなどのIdPにまずログインする
- サービスの選択：ポータル上の一覧から、使いたいサービス（SP）を選ぶ
- 応答の送信：IdPがSPへ応答（<Response>。認証アサーションを含む）を送る（SP Initiatedのステップ5に相当する）
- アクセスの許可：SPが応答を検証し、アクセスを許可する
すでにIdPにログイン済みの状態からサービスへ入っていくため、ポータルを起点に複数のサービスへ次々とアクセスする使い方に向いています。SPから入るかIdPから入るかという起点の違いはありますが、SPとIdPの間で応答（認証アサーション）をやり取りして認証する、という核になる仕組みは共通です。
SAMLの登場人物（IdP・SP・ユーザー）とSAMLアサーション
認証の流れを正しく読むために、登場人物とやり取りされる中身をもう少しかみ砕いておきます。SAML認証には「IdP」「SP」「ユーザー」の3者が登場し、その間を「SAMLアサーション」と呼ばれるデータが渡っていきます。
IdP・SP・ユーザーの役割
3者の役割は、次のように整理できます。SAML規格の用語定義にもとづくと、IdPとSPは信頼関係（フェデレーション）で結ばれた関係にあります。
- IdP（アイデンティティプロバイダー）：利用者の認証を行い、その結果を他のサービスに伝える「認証する側」。クラウド型のIDaaS（ID管理サービス）がこの役割を担います
- SP（サービスプロバイダー）：利用者が実際に使いたい「サービス側」。SaaS型の業務アプリ（メール・オンラインストレージなど）がこれにあたります
- ユーザー（principal＝利用者本人）：SPのサービスを使いたい利用者。IdPで認証を受け、その結果を持ってSPにアクセスします
IdPとSPがあらかじめ信頼関係を結んでいるからこそ、SPは「IdPが認証したユーザーなら信用してよい」と判断できます。ユーザーはIdPで一度認証を受ければ、信頼関係で結ばれた複数のSPにログインできるわけです。
SAMLアサーションとは（認証・属性・認可決定の3種）
SAMLアサーションとは、IdPが発行する「このユーザーについて確認できた事実」をXMLで記述した言明です。規格では、アサーションに含められる言明（statement）として、次の3種類が定義されています。
This SAML specification defines three different kinds of assertion statements that can be created by a SAML authority. … The three kinds of statement defined in this specification are:
出典：Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0｜OASIS
• Authentication: The assertion subject was authenticated by a particular means at a particular time.
• Attribute: The assertion subject is associated with the supplied attributes.
• Authorization Decision: A request to allow the assertion subject to access the specified resource has been granted or denied.
この定義は、SAMLのアサーションに3種類の言明があることを示しています。いつ・どの方法で認証したかを示す「認証」、所属や役職などの属性を示す「属性」、特定のリソースへのアクセスを許可・拒否したかを示す「認可決定」の3つです。
日本語にすると、認証アサーション（いつ・どの方法で認証されたか）、属性アサーション（所属や役職などの属性情報）、認可決定アサーション（特定のリソースへのアクセスを許可・拒否したか）の3種です。SSOで実際にやり取りされる中心は、認証アサーションと属性アサーションです。
3つ目の認可決定アサーションは、SAML 2.0の規格上で「今後の機能拡張は行わない（凍結）」とされており、アクセス権限の細かな制御には別規格であるXACML（アクセス制御専用の別規格）の利用が推奨されています。そのため、SAMLは実務上は主に認証（とユーザー属性の受け渡し）を担う規格だと理解しておくと、後述するOAuthとの違いも正確にとらえられます。
出典・参考資料（1件）
なぜSAML認証は安全か（署名・暗号化）
SAMLアサーションは、IdPからSPへネットワークを通じて渡されます。その途中で改ざんされたり盗み見られたりしないよう、SAMLには署名と暗号化の仕組みが備わっています。
署名には電子署名（XML Signature）が使われ、アサーションに署名することで「発行者が本当にそのIdPであること」と「内容が改ざんされていないこと」を受け取ったSP側で検証できます。規格では、署名が無効であればSPはそのアサーションの内容を信用してはならない、と定められています。これにより、第三者がアサーションを偽造したり書き換えたりするなりすまし・改ざんを防げます。
さらに、アサーション自体を暗号化（XML Encryption）して、途中経路での盗み見を防ぐこともできます。署名で改ざん・なりすましを防ぎ、暗号化で盗み見を防ぐ、という二重の備えが、SAMLでやり取りされる認証情報の安全性を支えています。
一括ダウンロードする
SAML認証のメリット・デメリット
SAML認証を導入するかどうかを判断するには、便益と裏返しのリスクを両面でつかんでおく必要があります。ここでは、SSOを実現する手段としてのメリットと、運用上のデメリットを整理します。
SAML認証のメリット
一度の認証で複数サービスにログインできる：IdPで一度認証すれば、信頼関係を結んだ複数のSPへ個別にログインし直す必要がなくなります。利用者はサービスごとのパスワード入力から解放され、日々のログインの手間が減ります。
パスワード管理と情シスの負担が軽くなる：認証をIdPに集約できるため、サービスごとにパスワードを使い回したり、付箋で管理したりといった運用を減らせます。情報システム部門にとっても、パスワードリセット対応やアカウント管理の手間を抑えやすくなります。
認証を一元管理でき、セキュリティを強化しやすい：認証がIdPに集まることで、多要素認証やアクセス制御のポリシーをIdP側でまとめて適用できます。どのサービスに誰がアクセスしたかの把握も一元化しやすくなります。
SAML認証のデメリット
認証基盤（IdP）が止まると影響範囲が広い：認証をIdPに集約する構造上、IdPに障害が起きると、そこにぶら下がる複数のサービスへログインできなくなるおそれがあります。利便性の裏返しとして、認証基盤が単一障害点になりやすい点は押さえておく必要があります。
認証情報が漏れると被害が広がりやすい：一度の認証で複数サービスに入れるということは、IdPのアカウントが乗っ取られた場合、連携する複数のサービスに不正アクセスされる危険があるということでもあります。IdPの認証そのものを多要素認証などで固く守ることが前提になります。
SAML非対応のサービスには別途対策が必要：SAMLはSPとIdPの双方が対応していて初めて成り立ちます。利用したいサービスがSAMLに対応していない場合は、別の連携方式を検討するか、そのサービスだけ個別のログイン運用を残すといった対応が必要になります。
SAML認証とOAuth・OpenID Connect・LDAPの違い（比較表）
SAMLは、OAuth・OpenID Connect・LDAPといった規格と並べて語られることが多く、混同されがちです。それぞれ「主に何を扱う規格か」が異なるため、違いを表で整理します。
| 規格 | SAML | OAuth 2.0 | OpenID Connect | LDAP |
|---|---|---|---|---|
| 主に扱うもの | 認証（SSO）。規格上は属性・認可決定の言明も定義するが、認可決定はSAML 2.0で凍結 | 認可（アクセス権限の委譲） | 認証（OAuth 2.0の上に乗るIDレイヤー） | ディレクトリ（ユーザー情報）へのアクセス |
| データ形式 | XML | トークン（JSON/JWT等） | JSON（JWT） | X.500ベースのディレクトリ |
| 主な用途 | 複数の業務サービスへの企業向けSSO（フェデレーション） | 第三者アプリに、必要な範囲だけAPIアクセスを許可する | WebアプリやモバイルアプリでのログインやSSO | 社内のユーザー情報の格納・問い合わせ・認証 |
認証と認可の違い（SAMLは主に認証、OAuthは認可）
これらの違いを理解する鍵が、「認証」と「認可」の区別です。認証は「相手が誰であるかを確かめること」（本人確認）、認可は「その相手に何をどこまで許可するかを決めること」（権限委譲）を指します。
SAMLは主に認証（本人確認）を扱い、その結果をSSOに使います。一方OAuth 2.0は、規格名が「The OAuth 2.0 Authorization Framework（認可のフレームワーク）」であるとおり、認可を扱う規格です。たとえば「あるアプリに、自分のカレンダーの閲覧だけを許可する」といった、アクセス権限の委譲を担います。
OAuth自体は利用者が誰かを確かめる認証の仕組みではないため、「SAML＝SSO」と「OAuth」を同じ土俵の認証規格として並べるのは正確ではありません。
OpenID Connectは、そのOAuth 2.0の上に「認証（本人確認）」のレイヤーを足した規格で、Webやモバイルのログインに使われます。LDAPは、社内のユーザー情報を格納・問い合わせするディレクトリへのアクセス規格であり、SAMLのようにサービス間で認証情報を受け渡すフェデレーションのための規格ではありません。扱う対象が異なる規格どうしだととらえると、混同を避けられます。
出典・参考資料（3件）
SAML認証を導入する際の注意点（IdP冗長化・単一障害点対策）
デメリットで触れた単一障害点や認証集約のリスクは、導入前に「どう手を打つか」を押さえておけば、製品選定の判断材料になります。ここでは対策の考え方に絞って整理します。
一般的に推奨される備えは、認証基盤そのものの可用性（止まりにくさ）を確保しておくことです。IdPを冗長化して1台が止まっても別の系統で認証を継続できるようにする、フェイルオーバー（自動切り替え）の仕組みを用意する、といった設計が考えられます。自社でIdPを構築する場合はこうした可用性設計を自前で検討する必要があります。
一方、クラウド型のIDaaS（IdP機能を提供するサービス）を利用する場合は、事業者側が冗長構成や稼働率（SLA）で可用性を担保していることが多く、自社で構築するより運用負荷を抑えやすくなります。製品を比較する際は、どの程度の稼働率をうたっているか、障害時の切り替えがどう設計されているかを確認しておくとよいでしょう。
あわせて、認証が集約されるIdPのアカウント自体を多要素認証で守ることも、被害を広げないための前提になります。
IdPを多要素認証でどう固めるかは、認証方式（SMS・アプリ・生体認証・FIDO2など）や製品によって選択肢が分かれます。認証方式ごとの違いや対応サービスの選び方を具体的に比べたい方は、以下の記事もあわせてご覧ください。
自社でSSOを実現するには（SAML対応のIDaaS・SSOの選び方）
SAML認証の仕組みを理解したら、次は「では自社でSSOを実現するには何を導入すればよいか」という検討に進みます。SAMLに対応したIdP機能は、多くの場合、クラウド型のIDaaS（Identity as a Service＝ID管理をクラウドで提供するサービス）として提供されています。
IDaaSを選ぶ際は、次のような観点を自社の状況に照らして確認すると、候補を絞り込みやすくなります。先ほどの導入注意点で挙げた可用性や多要素認証は、ここでは製品を比べるときに確認する観点として落とし込んでいます。
- 使いたいサービスがSAML（またはOpenID Connect）に対応しているか：SSOをかけたいクラウドサービスが、そのIDaaSと連携できるかを確認します。連携済みのアプリが一覧で用意されている製品だと、設定の手間を抑えやすくなります
- 多要素認証など認証強化の機能があるか：認証がIdPに集約される分、IdPを固く守る必要があります。パスキー（FIDO2）や多要素認証、アクセス制限などを組み合わせられるかを確認します
- 既存のID基盤と連携できるか：Active Directoryや人事システムと連携してアカウントを一元管理できると、入退社に伴うアカウント発行・停止の運用も効率化できます
- 可用性と料金が見合うか：認証基盤の止まりにくさ（稼働率・冗長構成）と、ユーザー単位などの料金体系を確認し、必要な規模・機能に見合うかを確かめます
これらの観点をもとに、SAMLに対応したIDaaSを具体的に比較検討したい方は、主要サービスの機能・料金・選び方や導入事例をまとめた以下の記事もあわせてご覧ください。
一括ダウンロードする
【比較表】SAML認証に対応した主なSSO・IDaaS
ここからは、SAML認証に対応した代表的なSSO・IDaaSを紹介します。まずは各サービスの特徴を一覧で比較します。
| サービス名 | CloudGate UNO | Okta（Workforce Identity Cloud） | Microsoft Entra ID |
|---|---|---|---|
| 提供形態 | クラウド（SaaS） | クラウド（SaaS） | クラウド（SaaS） |
| SAML認証（IdP） | ●SAML 2.0・OpenID Connect | ●SAML・OpenID Connect | ●SAML・OpenID Connect |
| 主な認証強化 | 多要素認証・FIDO2パスキー 生体認証・パスワードレス（全プラン対応） | 適応型MFA（Adaptive MFA） FIDO2・Okta FastPass（パスワードレス） | 多要素認証・条件付きアクセス パスキー（FIDO2）・Windows Hello |
| 料金目安 | 月額400〜600円/ユーザー（税抜） | 月額940円〜/ユーザー | 月額1,049円〜/ユーザー（無料版あり） |
| 詳細情報 | 公式資料を見る | サービス詳細を見る | サービス詳細を見る |
※本表は2026年10月時点の各社公式サイト情報に基づきます。料金・機能は変動するため、導入検討の際は各社公式サイトで最新情報をご確認ください。
SAML認証に対応したサービスの個別紹介
一覧で挙げた各サービスについて、SAML・SSOへの対応を中心に、どんな特徴があるかを個別に見ていきます。
1. CloudGate UNO（株式会社インターナショナルシステムリサーチ）
株式会社インターナショナルシステムリサーチ（ISR）が自社開発するクラウド型のID管理プラットフォームが、CloudGate UNOです。SSO・多要素認証・アクセス制限・ID管理を一つに統合したサービスで、同社はこれを「ゼロトラスト時代のSSO・アクセス制限・認証強化・ID管理プラットフォーム」と位置づけています。
SSOではSAML 2.0とOpenID Connectに対応し、IdPとしてSPへ認証情報を連携します。Google Workspace・Microsoft 365・Salesforce・Slackなど多数のクラウドサービスと連携でき、一度の認証で複数サービスへのアクセスをまとめられます。
認証を集約するIdP側を固める手段として、パスキー（FIDO2）によるパスワードレス認証を全プラン・全ユーザーで利用できる点も特徴です。SAMLによるSSOと、フィッシングに強い認証強化を一つの基盤でまとめて運用したい場合に向いています。
SSOとあわせてパスワードレス化を進めると、情報システム部門のパスワード関連業務にどの程度の変化が表れるのか。同社は導入現場での一例を次のように挙げています。
導入と同時にパスワードレス認証に切り替えた企業では、IT部門の業務の約20%を占めていたパスワード関連のヘルプデスク業務が「0%」になったという事例があります。
2. Okta（Okta Japan株式会社）
Okta Workforce Identity Cloudは、SSO・多要素認証・ユーザーディレクトリ・IDライフサイクル管理を一つに統合した、従業員向けのクラウド型IDaaSです。開発元はOkta, Inc.で、国内はOkta Japan株式会社が提供しています。
フェデレーションSSOはSAMLとOpenID Connectの2つのプロトコルに対応します。あらかじめ用意された連携（Okta Integration Network）は2026年10月時点で8,000を超え、Slack・Google Workspace・Salesforceをはじめ数千のアプリケーションとSSOでつなげられる点が強みです。
アクセスのたびに状況を評価して認証の強さを変えるアダプティブ多要素認証や、入社・異動・退職に合わせてアカウントを自動で作成・停止するライフサイクル管理もあわせて利用できます。多数のSaaSを横断して認証を一元化したい企業に向いた構成です。
3. Microsoft Entra ID（日本マイクロソフト株式会社）
Microsoft Entra IDは、日本マイクロソフト株式会社が提供するクラウド型のID・アクセス管理（IAM）サービスで、2023年に「Azure Active Directory（Azure AD）」から名称変更されました。Microsoft 365やAzureの認証基盤そのものを担い、SSO・多要素認証・条件付きアクセスを提供します。
アプリケーションギャラリーには事前に統合された多数のSaaSアプリがそろい、各アプリをSAMLやOpenID Connectなどの方式でSSO連携できます。Microsoft 365やAzureをすでに利用している組織であれば、別途の製品を導入せずにこれらのSSO・認証機能を有効化できる点が特徴です。
条件付きアクセスにより、利用者・場所・デバイスなどの条件に応じてアクセスの可否や追加認証を動的に制御でき、アカウントの自動プロビジョニング（作成・更新・無効化）も備えます。Windowsや既存のActive Directory環境との親和性を活かして認証基盤を整えたい企業に向いています。
まとめ
SAML認証は、XMLをベースにした標準規格SAMLを使い、IdP（認証する側）とSP（使いたいサービス側）の間で認証情報を安全に受け渡す仕組みです。SAML自体はSSOそのものではなく、SSOを実現する手段の一つ（フェデレーション方式）であり、SAML 2.0はOASISが2005年に標準化した規格です。
認証の流れには、使いたいサービスから始まるSP Initiatedと、ポータルなどのIdPから始まるIdP Initiatedの2方式があります。いずれも署名・暗号化によってアサーションの改ざんや盗み見を防いでいます。OAuthは認可、OpenID ConnectはOAuth上の認証、LDAPはディレクトリアクセスと、扱う対象が異なる規格だと押さえると混同を避けられます。
導入にあたっては、認証基盤が単一障害点になりやすい点を踏まえ、可用性や認証強化もあわせて検討することが大切です。SAMLに対応したSSOは多くの場合IDaaSの機能として提供されるため、連携できるサービス・認証強化機能・既存基盤との連携・料金を確認し、自社に合った製品を選ぶとよいでしょう。
よくある質問（FAQ）
Q. SAMLとOAuthの違いは何ですか？
A. SAMLとOAuthの違いは、SAMLが主に「認証（本人確認）」を扱うのに対し、OAuth 2.0は「認可（アクセス権限の委譲）」を扱う点にあります。OAuth自体は利用者が誰かを確かめる認証の仕組みではないため、両者を同じ認証規格として並べるのは正確ではありません。データ形式も、SAMLはXML、OAuthはJSON（アクセストークン）と異なります。
Q. SAML認証の設定はどう始めればよいですか？
A. SAML認証の設定は、IdP側とSP側で、証明書やエンドポイントURLなどを記したメタデータ（連携情報）を相互に登録し、両者の信頼関係を結ぶところから始めます。多くのクラウドサービスは、連携手順やメタデータの取得先を公開しています。
SAMLに対応したIDaaSを使う場合は、あらかじめ用意された主要サービスとの連携設定を利用でき、一から構成するより設定の手間を抑えやすくなります。既存のIDaaSを活用するのが近道です。
Q. 既存のActive DirectoryやLDAPと併用できますか？
A. 多くのIDaaSはActive DirectoryやLDAPと連携でき、社内のID基盤と同期しながらIdPとして振る舞う構成が一般的です。これにより、社内のユーザー情報を既存のディレクトリで一元管理したまま、クラウドサービスへのSAML認証によるSSOを実現できます。
Q. IdP Initiatedで注意すべきセキュリティ点は何ですか？
A. IdP Initiatedでは、SPがリクエストしていないアサーションを受け取って処理するため、信頼できないIdPからの不正なアサーションを受理してしまうリスクに注意が必要です。対策として、連携するIdPを信頼済みのものに限定し、アサーションの署名検証や有効期限などの設定を適切に行うことが求められます。
Q. 自社でSAML認証によるSSOを実現するには何を導入すればよいですか？
A. 自社でSAML認証によるSSOを実現するには、SAMLに対応したIdP機能を持つクラウド型のIDaaS（ID管理サービス）を導入するのが一般的です。CloudGate UNO・Okta・Microsoft Entra IDなどがSAML 2.0に対応しています。
使いたいサービスとの連携可否、多要素認証など認証強化の機能、既存のID基盤との連携、可用性と料金を、自社の状況に照らして比較するとよいでしょう。
SAML認証に対応したSSO・IDaaSの料金・資料を一括チェック
MCB FinTechカタログでは、SAML認証に対応したSSO・IDaaSの最新資料を無料で一括請求できます。連携できるサービス・認証強化機能・既存基盤との連携・料金を横断で比較できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
