社内で使うSaaS（クラウド型の業務サービス）が増えるほど、サービスごとに発行されるIDとパスワードの管理は重くなります。利用者はログインのたびに異なるパスワードを入力し、情報システム部門は入社・異動・退職のたびに全サービスのアカウントを個別に手当てしなければなりません。この負担を解消する仕組みがSSO（シングルサインオン）であり、SaaSのSSOを実現する代表的な規格が「SAML」です。
とはいえ、「SSOにはSAMLが要るらしい」と聞いても、SAMLが具体的に何をする規格で、SaaSへのログインをどう成立させているのかは、言葉だけではつかみにくいものです。OAuthやOpenID Connectとの違い、自社で使うSaaSがSAMLに対応していなかった場合の扱いも、あわせて整理しておきたいところです。
SAMLには「自社でSaaSを使う側（SSOを導入する）」と「自社でSaaSを提供する側（自社サービスをSAML対応させる）」の2つの関わり方があります。本記事は前者、SSOを導入する側（SaaSを利用する企業）の視点で解説します。
本記事では、SAML認証の仕組みを登場人物と流れから結論ファーストで解説し、OAuth・OpenID Connectとの使い分け、導入のメリットと運用上の注意点、SAML非対応SaaSへの対処までを整理します。
あわせて、SAMLでSaaSのSSOを実現する主要なIDaaS（アイダース／ID管理システム）・IdP製品を比較表と診断で紹介し、製品選定の入り口までを一気通貫でたどれるようにしました。情報システム・セキュリティ部門の担当者が、自社のSSO基盤を検討する際の判断材料としてご活用ください。
また、自社の状況に合うSAML対応のIDaaSを最短で見つけられるよう、「数問で終わる選定診断ツール」も用意しています。製品選びの出発点としてお役立てください。
目次
一括ダウンロードする
SAML認証とは？SaaSのSSOを実現する認証規格
SAML（サムル）は、複数のSaaSやシステムに1回のログインでアクセスできるSSOを実現するための、認証情報をやり取りする標準規格です。
正式名称はSecurity Assertion Markup Language（セキュリティ・アサーション・マークアップ・ランゲージ）で、XMLという形式を使って「このユーザーは確かに本人である」という認証の結果を、認証する側と利用される側のサービスの間で安全に受け渡します。
標準化を担うのは、国際的な標準化団体OASIS（Organization for the Advancement of Structured Information Standards）です。SAML 2.0は2005年にOASIS標準として策定され、現在も企業向けSSOの中心的な規格として広く使われています。規格の定義そのものは、次のように示されています。
The OASIS Security Assertion Markup Language (SAML) standard defines an XML-based framework for describing and exchanging security information between on-line business partners.
出典：Security Assertion Markup Language (SAML) V2.0 Technical Overview｜OASIS Security Services Technical Committee
（SAML標準は、オンライン上の取引先企業間でセキュリティ情報を記述し交換するための、XMLベースのフレームワークを定義する）
このようにSAMLは、サービスをまたいでセキュリティ情報（ここでは認証結果）をやり取りする「共通の言語」にあたります。この共通言語があることで、利用者が一度ログインすれば、その認証結果を各SaaSが信頼してログイン状態を引き継げるようになります。読み方は英語の頭文字をそのまま読んで「サムル」と呼ばれるのが一般的です。
出典・参考資料（2件）
SaaSのSSOはどういう仕組みで成立するのか
ここからは、SAMLがSaaSのSSOをどう成立させているのかを、登場人物と流れから見ていきます。仕組みをつかむ鍵は、「誰が」「誰に」「何を」渡してログインが成立するのかという3点です。
SAML認証を支える3者（IdP・SP・ユーザー）
SAMLによるSSOには、3人の登場人物がいます。1人目はユーザー（利用者本人）、2人目はIdP（アイデンティティプロバイダー）、3人目はSP（サービスプロバイダー）です。
IdPは、ユーザーが本人かどうかを確認し、認証を担う側です。IDaaSやActive Directory連携の認証基盤がこの役割を果たします。SPは、ユーザーが実際に使いたいSaaSなど、認証結果を受け取ってログインを許可する側です。SAMLは、このIdPとSPという2つの役割を規格として定義しています。
To support Multi-Domain Single Sign-On (MDSSO, or often just SSO), SAML defines the roles called identity provider (IdP) and service provider (SP).
出典：SAML V2.0 Technical Overview §3.1｜OASIS Security Services Technical Committee
（複数ドメインにまたがるシングルサインオンを実現するため、SAMLはIdP（アイデンティティプロバイダー）とSP（サービスプロバイダー）という役割を定義している）
ユーザーはIdPに対して一度だけ本人確認を行い、その結果を複数のSP（SaaS）が信頼する——これがSAMLによるSSOの骨格です。IdPが「本人確認の窓口」を一手に引き受けることで、SaaSごとに個別のログインを繰り返す必要がなくなります。
出典・参考資料（1件）
- 出典：Security Assertion Markup Language (SAML) V2.0 Technical Overview §3.1｜OASIS Security Services Technical Committee（リンク）
認証の中心「SAMLアサーション」とは
IdPからSPへ渡される認証結果の本体が、SAMLアサーションです。アサーションは、ユーザー（プリンシパル）について「この人は認証済みである」といった事実を伝えるためのデータで、規格では次のように定義されています。
SAML assertions carry statements about a principal that an asserting party claims to be true.
出典：SAML V2.0 Technical Overview §4.1｜OASIS Security Services Technical Committee
（SAMLアサーションは、主張する側が真であると表明する、プリンシパル〈ユーザー〉に関する言明を運ぶ）
アサーションはXML形式のデータであり、IdPによる電子署名を付けて受け渡されます。署名によって、SPは受け取ったアサーションが確かにそのIdPから発行され、途中で改ざんされていないことを検証できます。利用者からは見えないところで、この署名付きのデータがIdPとSPの間を行き来することで、なりすましや改ざんを防ぎながら認証結果を安全に引き継いでいます。
SSOが成立するまでの流れ（2つのログインパターン）
SAMLのSSOには、ログインをどこから始めるかで2つのパターンがあります。SAML 2.0はこの両方に対応しています。
SP-Initiated（SP起点）は、ユーザーがまず使いたいSaaS（SP）にアクセスし、そこからIdPへ送られてログインするパターンです。流れは次のとおりです。
- ユーザーが使いたいSaaS（SP）にアクセスする
- SPが「まだ認証されていない」と判断し、ユーザーをIdPへ転送する
- IdPでユーザーが本人確認（ID・パスワードや多要素認証）を行う
- IdPが署名付きのSAMLアサーションを発行し、SPへ渡す
- SPがアサーションを検証し、ユーザーのログインを許可する
一方のIdP-Initiated（IdP起点）は、ユーザーが先にIdP（社内ポータルなど）で認証を済ませ、そこに並ぶSaaSへのリンクをクリックしてログインするパターンです。社員向けのSaaS一覧ポータルから各サービスへ移動する動線が典型例です。
- ユーザーがIdP（社内ポータルなど）で本人確認を済ませる
- ポータルに並ぶ、使いたいSaaSへのリンクをクリックする
- IdPが署名付きのSAMLアサーションを発行し、SPへ渡す
- SPがアサーションを検証し、追加のログインなしで利用できる
出典・参考資料（1件）
- 出典：Security Assertion Markup Language (SAML) V2.0 Technical Overview §3.2・§5.1.1｜OASIS Security Services Technical Committee（リンク）
SAMLとSSOの違い（SAMLは「SSOを実現する手段」）
SAMLとSSOは混同されがちですが、両者は「手段」と「目的」の関係にあります。SSOは「1回のログインで複数のサービスを使える状態」という目的を指す言葉で、SAMLはそれを実現する手段のひとつです。
SSOを実現する手段はSAMLだけではなく、後述するOpenID Connectや、社内ネットワークで使われるKerberos認証などもあります。そのなかでSAMLは、企業が業務で使うSaaSのSSOにおいて広く採用されている規格だと理解しておくと、製品選びの軸がぶれません。
SAMLとOAuth・OpenID Connect（OIDC）の違い
SAMLと並んで名前が挙がるのがOAuth（オーオース）とOpenID Connect（オープンアイディー・コネクト、以下OIDC）です。「結局どれを使えばいいのか」を判断するには、それぞれが担う役割の違いを押さえるのが近道です。ポイントは、認証（本人かどうかの確認）なのか、認可（何にアクセスしてよいかの許可）なのかという違いにあります。
OAuth 2.0は、仕様上「認可（authorization）のフレームワーク」と定義されています。あるアプリが、ユーザーに代わって別のサービスのデータへ限定的にアクセスする許可を得るための仕組みで、「このユーザーが誰か」を保証することを主目的とはしていません。
そのOAuth 2.0の上に本人確認（アイデンティティ）の層を足したものがOIDCです。OIDCの仕様では「OAuth 2.0プロトコルの上に構築された、シンプルなアイデンティティ層」と説明されており、認可の枠組みを土台にしながら「ユーザーが誰か」を検証できるようにしています。したがって役割を整理すると、SAMLとOIDCは認証（＋SSO）を担い、OAuthは認可を担うという関係になります。
| 規格 | 主な役割 | データ形式 | 主な使いどころ |
|---|---|---|---|
| SAML 2.0 | 認証・SSO | XML | 社内で使う業務SaaS・社内システムのSSO |
| OpenID Connect（OIDC） | 認証・SSO（OAuth 2.0＋認証層） | JSON／JWT | 新規開発のWebサービス・スマホアプリのログイン |
| OAuth 2.0 | 認可（アクセス権の委譲） | JSON／トークン | 他サービスのデータへの限定的なアクセス許可 |
実務的な選び分けの目安としては、社員向けに既存の業務SaaSをまとめてSSO化するならSAML、これから開発するWebサービスやスマホアプリのログインを設計するならOIDCが第一候補になります。OAuthは単体でログイン（認証）に使うものではなく、OIDCやSAMLと役割が異なる点に注意してください。
製品選定の実務では、SaaSのSSO文脈においてSAMLは「認証結果の受け渡し役」と理解しておけば十分です（厳密にはSAMLは規格として属性情報なども扱えますが、使い分けの判断にはこの理解で問題ありません）。
出典・参考資料（2件）
SAML認証でSaaSのSSOを導入するメリット
SAMLによるSSOを導入すると、利用者・情報システム部門の双方に次の3つのメリットが生まれます。
利用者の利便性が上がる。SaaSごとに異なるIDとパスワードを覚えて入力する手間がなくなり、一度のログインで必要なサービスに入れるようになります。パスワードを使い回したり、付箋に書き留めたりといった危うい運用も減らせます。
セキュリティを強化できる。認証をIdPに集約することで、多要素認証やアクセス制御をIdP側でまとめて適用できます。パスワードがSaaSごとに分散せず、IdPで一元的に本人確認を行うため、弱いパスワードや使い回しに起因する不正ログインのリスクを下げられます。
情報システム部門の管理が効率化する。アカウントの発行・権限変更・停止をIdPで一元管理できるため、SaaSごとに同じ作業を繰り返す必要がなくなります。特に入社・異動・退職の際のアカウント手当てを集約でき、管理工数と設定漏れの両方を減らせます。
SAML認証のデメリットと運用上の注意点
メリットの裏側で、SAMLによるSSOには構造上の弱点もあります。導入後に慌てないために、次の4つの注意点を押さえておきましょう。いずれも、認証をIdPに集約するという仕組みそのものから生じる論理的な帰結です。
IdPが単一障害点になる。認証をIdPに一本化するということは、IdPが停止すると、そこに連携するすべてのSaaSにログインできなくなるということでもあります。業務の入り口を1か所に束ねる以上、IdPの可用性（止まらない設計・冗長化）は導入前に必ず確認すべき点です。
乗っ取り時の影響範囲が広がる。IdPのアカウントが乗っ取られると、連携する全SaaSへのアクセスを同時に許してしまいます。認証を集約するほど、IdP側の守り——多要素認証や条件付きアクセスなど——の重要性が増します。利便性の裏返しとして、IdPが攻撃の標的になりやすい点を理解しておく必要があります。
証明書の期限切れが一斉障害につながる。SAMLはIdPとSPの間で電子証明書を使って信頼関係を結びます。この証明書には有効期限があり、更新を忘れると、ある日突然すべての連携SaaSでログインできなくなります。証明書の期限管理は、SSO運用で見落とされやすい代表的な落とし穴です。
退職者アカウントの停止漏れに注意する。SSOを入れても、SaaS側に個別アカウントが残っていれば、退職者がそのまま使えてしまう可能性があります。IdPでの停止と各SaaSのアカウント停止を確実に連動させる運用設計が欠かせません。この自動連動を担うのが、後述するSCIMによるアカウント同期です。
SAML非対応のSaaSはどう扱う？代替手段とSCIMとの役割分担
SSOを進めるうえで必ずぶつかるのが、「使いたいSaaSがSAMLに対応していない」というケースです。ここでは、非対応SaaSの現実的な扱い方と、SAMLだけでは解決しないアカウント管理をどう補うのかを整理します。
SAML非対応のSaaSを使うときの代替手段
SaaSがSAMLに対応していない場合でも、SSOに近い使い勝手を実現する方法があります。多くのIDaaSは、SAML以外の方式も組み合わせてカバーしています。
代表的なのが、IdPがID・パスワードを安全に預かって自動入力する代理認証（フォーム認証型）です。SaaS側の対応状況に左右されにくく、SAML非対応のサービスでもシングルサインオンに近い体験を提供できます。
このほか、ユーザーとSaaSの通信を仲介するリバースプロキシ型の方式を使う製品もあります。自社で使う非対応SaaSにどの方式が使えるかは、IDaaS製品ごとに対応範囲が異なるため、導入前に確認しておくと安心です。
フォームベース認証に対応したIDaaSを選べば、SAML非対応のSaaSも含めてSSOでまとめやすくなります。どの製品がどの方式に対応するかは、後述の比較表の「SAML 2.0」以外の列であわせて確認してみてください。
SAML（認証）とSCIM（ID同期）の役割分担
SSOを設計するうえで、SAMLと必ずセットで理解しておきたいのがSCIM（スキム）です。SAMLがログインの「認証」を担うのに対し、SCIMはアカウント情報の「同期（プロビジョニング）」を担います。両者は役割が異なり、組み合わせることでSSO運用が完成します。
SCIMは、正式名称をSystem for Cross-domain Identity Managementといい、異なるサービス間でユーザーアカウントの作成・更新・削除を標準化された方法で自動的に反映するためのプロトコルです。これにより、IdPでアカウントを停止すれば各SaaS側のアカウントも自動で止まる、といった連動が実現します。
| 項目 | SAML | SCIM |
|---|---|---|
| 担う役割 | 認証（ログインの可否） | ID同期（アカウントの自動反映） |
| たとえると | 入室時の本人確認 | 名簿への自動登録・削除 |
| いつ働くか | ユーザーがログインする瞬間 | アカウントの発行・変更・停止のとき |
| 解決すること | パスワードの分散・ログインの手間 | アカウント作成・停止漏れ |
このように、SAMLで「ログインを一元化」し、SCIMで「アカウントの棚卸しを自動化」する——この2つがそろって初めて、入社から退職までのアカウント管理が抜け漏れなく回ります。SSO基盤を選ぶ際は、SAMLだけでなくSCIMへの対応状況もあわせて確認しておくと、運用の負担を大きく減らせます。
出典・参考資料（2件）
一括ダウンロードする
SAML認証に対応した主要IDaaS／IdP製品
ここからは、SAMLでSaaSのSSOを実現するIdPとなる、主要なIDaaS製品を紹介します。IDaaSは、SSO・多要素認証・ID管理などをクラウドで提供するサービスで、SAMLに対応した製品を選べば、対応SaaSのSSOをまとめて実現できます。まずは比較表で全体像をつかみ、続く診断と個別紹介で自社に合う候補を絞り込んでください。
| サービス名 | CloudGate UNO | Microsoft Entra ID | Okta | HENNGE One | トラスト・ログイン byGMO | IIJ IDサービス | OneLogin |
|---|---|---|---|---|---|---|---|
| 提供元 | 国産 | 海外（米国） | 海外（米国） | 国産 | 国産 | 国産 | 海外（米国） |
| SAML 2.0 | ● | ● | ● | ● | ● | ● | ● |
| OpenID Connect | ● | ● | ● | ● | ● | ● | ● |
| SCIM（ID同期） | △プロビジョニング・AD連携 | ●SCIM 2.0 | ●SCIM標準 | △JITプロビジョニング（対応SaaS限定） | ●プロビジョニング（100アプリ超） | △AD連携で同期 | ●SCIM 1.1/2.0 |
| 多要素認証（MFA） | FIDO2・パスキー、生体認証、OTP、認証アプリ | Authenticator、パスキー(FIDO2)、Windows Hello、OTP、SMS・音声 | Okta Verify、FastPass、FIDO2/WebAuthn、OTP、SMS・音声・メール | OTP、プッシュ承認（HENNGE Lock）、デバイス証明書 | アプリ/メールOTP、パスキー(FIDO2)、プッシュ通知、顔認証 | FIDO2、デバイス証明書、メールOTP、SmartKey、統合Windows認証 | OneLogin Protect（プッシュ/OTP）、WebAuthn(FIDO2)、SMS・音声・メール |
| パスワードレス | ●全プラン無制限 | ●パスキー・Windows Hello | ●FastPass・FIDO2 | 要確認 | ●有料プラン（SSOプロ） | ●FIDO2 | ●WebAuthn(FIDO2) |
| 料金目安 | 月額400〜600円/ユーザー（税抜） | 無料〜1,499円/ユーザー（年払い） | 940円〜/ユーザー（年払い） | 400円〜/ユーザー（税抜、IdP） | 無料〜300円/ユーザー（税抜） | 120〜240円/ユーザー（税抜） ※2026年11月に価格改定・最新は要確認 | 要問い合わせ（代理店による） |
| 詳細情報 | 公式資料を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る |
●＝標準対応／△＝条件付き・限定対応／要確認＝公式情報で対応可否を確認できなかった項目。料金・対応状況は2026年11月時点の各社公式情報に基づく目安です。
比較表に示した料金はあくまで目安です。月額・初期費用・オプション費用の実額を各サービス横並びで確認したい場合は、公式の料金ページをもとに整理した以下の記事もあわせてご覧ください。
SAML対応IDaaSをかんたん選定診断
1. CloudGate UNO（株式会社インターナショナルシステムリサーチ）
CloudGate UNOは、株式会社インターナショナルシステムリサーチ（ISR）が100％自社開発で提供する国産のIDaaS（クラウド型のID管理基盤）です。ゼロトラストの考え方に基づくシングルサインオン（SSO）を軸に、多要素認証（MFA）・アクセス制限・ID管理までを1つの管理画面で扱えるのが特徴です。
SSOはSAML 2.0・OpenID Connect・フォームベース認証に対応し、Google Workspace・Microsoft 365・Salesforce・Slackなどへ一度のログインでアクセスできます。
認証強化の面では、パスキー（FIDO2＝パスワードに頼らずデバイスの生体認証などで本人確認する規格）を早くから手がけてきた点が強みです。2014年にFIDOアライアンスへ参画し、2019年にはFIDO2準拠のパスワードレス認証を提供開始しました。このパスキー認証は全プラン・全ユーザーで無制限に使えます。
アクセス制限は「端末・場所・時間」の3軸で細かく設定でき、私用端末の排除や拠点・時間帯による制御まで可能です。導入前から導入後まで日本語で手厚く支援する体制も整っています。オンプレミスからクラウドへ移行して複数のSaaS利用を始めた企業が、安全なSSO環境を短期間で構築したいときに適しています。
パスワードレス認証への移行が情報システム部門の運用にどのような効果をもたらすかについて、提供元のインターナショナルシステムリサーチは独自インタビューで次のような事例を挙げています。
導入と同時にパスワードレス認証に切り替えた企業では、IT部門の業務の約20%を占めていたパスワード関連のヘルプデスク業務が「0%」になったという事例があります。
出典・参考資料（1件）
- 出典：CloudGate UNO、FIDO2認定のパスワードレス認証を提供開始｜株式会社インターナショナルシステムリサーチ（リンク）
2. Microsoft Entra ID（Microsoft Corporation）
旧称Azure Active Directoryとして知られてきたMicrosoft Entra IDは、Microsoftが提供するクラウド型のID・アクセス管理（IAM）サービスです。Microsoft 365やAzureのサインイン基盤そのものであり、SSO・多要素認証・条件付きアクセス・パスワードレス認証を1つのID基盤で担います。
事前統合された何千ものアプリを収録したアプリギャラリーを備え、各アプリはSAML／OpenID ConnectによるSSOに対応します。
アカウント管理の自動化にも強く、SCIM 2.0（アプリ間でユーザー情報をやり取りする標準規格）に対応したプロビジョニング（アカウントの自動作成・更新・削除）を提供します。人事システムや入退社のワークフローと連携した自動化まで踏み込めますが、グループ単位の自動化やオンプレミス連携などは上位ライセンス（P1以上）が前提になる点は確認しておきたいところです。
すでにMicrosoft 365・Windows・Azureを標準利用している組織であれば、別途MFA製品を足さずに同じID基盤の中でSSOや認証強化を有効化できるのが大きな利点です。無料のFreeから有償のP1・P2まで段階があり、使いたい機能に応じて選ぶ形になります。
3. Okta（Okta, Inc.）
Oktaは、特定のベンダーに縛られない中立的なIDaaSです。米Oktaの公表では、Fortune 100企業の3分の2を含む世界中の組織に利用されています。
本記事が扱うのは従業員・委託先向けの「Okta Workforce Identity Cloud」で、SSO・多要素認証・ユーザーディレクトリ・IDライフサイクル管理を統合的に提供します。フェデレーションSSOはSAMLとOpenID Connectの両方に対応します。
連携の広さが際立つ点で、事前構築済みの連携カタログ「Okta Integration Network（OIN）」は8,000を超えます。SCIM標準を用いてこれら多数のアプリへ自動プロビジョニングでき、Workday・SAP SuccessFactorsなどの人事システムと接続すれば、入社・異動・退職に伴うアカウント作成や即時のアクセス失効までを自動化できます。
認証面では、デバイスにひも付いた鍵で本人確認するフィッシング耐性の高いパスワードレス認証「Okta FastPass」やFIDO2/WebAuthnに対応し、リスクに応じて認証を強めるアダプティブMFAも備えます。マルチベンダーのSaaSを数多く使う企業や、ID基盤を特定のクラウドに依存させたくない企業に向いています。
出典・参考資料（2件）
4. HENNGE One（HENNGE株式会社）
HENNGE Oneは、SSO・多要素認証・アクセス制御によるID統制に、メールセキュリティやエンドポイント対策を組み合わせた国産のクラウドセキュリティ基盤です。IDaaS（IDプロバイダー）としての機能はIdentity Editionが担い、SAMLなどによるクラウドサービスへのSSOを提供します。契約ユーザー数は300万を超え、東証上場企業の約2割が利用するなど国内での導入実績が豊富です。
SSOは連携するSaaSの数が増えても追加課金が発生しない料金設計で、多くのクラウドサービスに対応します。アクセス制御ではIPアドレス制限やデバイス証明書による端末制御が可能です。退職者アカウントの自動処理につながるユーザープロビジョニング機能も備わりますが、対応SaaSは順次拡大中の段階なので、自社で使うサービスが対象かは確認しておくとよいでしょう。
Identity・DLP・Cybersecurityの3エディションを単体でも全部入りのSuiteでも契約でき、ID統制を起点にメール誤送信対策や脅威対策まで同じ基盤でまとめたい企業に適しています。
出典・参考資料（1件）
- 出典：HENNGE One 契約ユーザー数300万突破のお知らせ｜HENNGE株式会社（リンク）
5. トラスト・ログイン byGMO（GMOグローバルサイン株式会社）
電子認証局を運営するGMOグローバルサインが手がけるトラスト・ログイン byGMOは、基本機能を無料プランから使い始められる点を訴求する企業向けIDaaSです。SSOはSAML認証・OIDC認証・フォームベース認証・Basic認証に対応し、無料プラン（SSOフリー）でもアカウント数・連携アプリ数ともに無制限で利用できます。
認証強化の手段は幅広く、アプリ型・メール型のワンタイムパスワード、パスキー（FIDO2）、プッシュ通知、デスクトップSSO、顔認証などを選べます。ただしパスキーをはじめとするパスワードレス機能は有料のSSOプロプランが対象なので、無料で始めつつMFAを強化する場合はプランの切り分けを押さえておきたいところです。
2026年にはグループ企業でSAML設定を共有できる「組織間連携（Hub and Spoke方式）」やサプライチェーン向けプランを相次いで追加しており、複数の子会社や取引先を抱える企業のID統制にも広がりを見せています。まずは無料でSSOを試し、必要に応じて機能を足していきたい企業に向いています。
6. IIJ IDサービス（株式会社インターネットイニシアティブ）
国内通信事業者のIIJが自社で開発・運用するIIJ IDサービスは、SSOとアクセス制御を中核に多要素認証を内包したクラウド型のID管理サービスです。SSOはSAML 2.0とOpenID Connect 1.0に準拠し、連携するサービス数を増やしても料金が変わらないのが特徴です。
多要素認証の方式が豊富で、FIDO2によるパスワードレス認証、自社CA・外部CAの両方に対応したデバイス証明書認証、メールOTP、スマホアプリによるSmartKey認証、統合Windows認証などから選べます。オンプレミスのActive Directoryと連携してID・パスワード・グループ情報を自動同期し、グループ単位で認可を制御できる点も実務で効いてきます。
初期費用0円で、ID単価も「SSOのみ」「SSO＋多要素認証」の2段階で公開されています。2025年末にISMAP（政府情報システム向けのセキュリティ評価制度）のクラウドサービスリストへ登録されており、政府調達の基準を意識する大企業のID基盤選定でも検討材料になります。
出典・参考資料（1件）
- 出典：IIJ IDサービスがISMAPクラウドサービスリストに登録｜株式会社インターネットイニシアティブ（リンク）
7. OneLogin（One Identity LLC）
OneLoginは、米One Identity（Quest Software傘下）が提供するエンタープライズ向けのクラウドIAM／IDaaSです。社員・顧客・パートナーのアイデンティティを一元管理し、SSO・多要素認証・ディレクトリ連携・ユーザープロビジョニングを統合します。
SSOはSAML・OpenID Connect・SCIM・APIベースのプロビジョニングに対応し、事前統合アプリのカタログは6,000を超えます。
アカウント管理の自動化では、Active Directory上の追加・変更・削除を検出して連携先クラウドのアカウントへリアルタイム〜15分以内に反映できます。SCIMは1.1と2.0の両方に対応します。
認証面では機械学習エンジン「Vigilance AI」を使ったアダプティブ認証「SmartFactor Authentication」を備え、ログインごとのリスクに応じて認証要件を動的に変えられます。
ただし、日本市場では本体の直販ではなく国内代理店を通じた販売・サポートが基本で、料金やプラン構成は代理店によって異なります。グローバルでの導入実績を重視しつつ、クラウドとオンプレミスが混在する環境でID基盤を統合したい企業に向いています。導入条件や円建て料金は取扱代理店への確認が前提になります。
出典・参考資料（1件）
- 出典：OneLogin App Catalog（事前統合アプリ数）｜One Identity LLC（リンク）
SAMLへの対応は、IDaaSを選ぶ際の一要素にすぎません。IDaaSそのものの選び方やメリット・導入事例まで含めて全体像を押さえたい方は、以下の記事であわせて確認できます。
SaaSのSSOを導入する前に確認したいこと
製品の候補が見えてきたら、導入後につまずかないために、次の点を事前に確認しておくと安心です。
使いたいSaaSがどのプランでSSOに対応しているか。SaaSのなかには、SAMLやSSO連携を上位プラン限定の機能として提供しているものが少なくありません。現在契約しているプランでSSOが使えるのか、使えない場合はどのプランへの変更が必要かを、各SaaSの公式料金ページで確認しておきましょう。
属性情報のマッピングが自社の運用に合うか。SSOでは、メールアドレスや部署などの属性情報をIdPからSPへ渡します。自社で使いたい項目が連携できるか、ユーザーの識別子（NameID）として何を使うかを事前にすり合わせておくと、導入時の手戻りを防げます。
多要素認証やアカウント同期まで含めて設計できるか。SSOはログインの入り口を一元化する仕組みです。前述のとおりIdPが単一障害点になりやすいため、多要素認証（MFA）の併用や、SCIMによるアカウント同期まで含めて検討すると、利便性とセキュリティを両立しやすくなります。
まとめ
SAML（サムル）は、XMLで認証結果を受け渡すことでSaaSのSSOを実現する標準規格です。IdP・SP・アサーションという登場人物と、SP-Initiated／IdP-Initiatedの2つの流れを押さえれば、仕組みの全体像はつかめます。OAuthは認可、OIDCはOAuthに認証を足したものと整理でき、社内の業務SaaSをまとめてSSO化するならSAMLが第一候補になります。
導入にあたっては、IdPの単一障害点や証明書の期限管理といった運用上の注意点と、SAML非対応SaaSの扱い・SCIMによるアカウント同期まで視野に入れることが、失敗しないSSO基盤づくりの鍵です。自社に合うIDaaSを比較・診断して、まずは気になる製品の資料から確認してみてください。
一括ダウンロードする
よくある質問（FAQ）
Q. SAMLとは何ですか？読み方は何と読みますか？
A. SAMLは、複数のSaaSやシステムに1回のログインでアクセスできるSSO（シングルサインオン）を実現するための認証規格で、「サムル」と読みます。正式名称はSecurity Assertion Markup Languageで、XML形式で認証の結果（アサーション）を、認証する側のIdPと利用されるサービス（SP）の間で安全に受け渡します。
Q. SAMLとSSOの違いは何ですか？
A. SAMLとSSOは、「手段」と「目的」の関係にあります。SSOは「1回のログインで複数のサービスを使える状態」という目的を指す言葉で、SAMLはそれを実現する手段のひとつです。SSOを実現する手段にはSAMLのほかOpenID ConnectやKerberos認証などもありますが、企業が業務で使うSaaSのSSOではSAMLが広く採用されています。
Q. SAMLとOAuth・OpenID Connect（OIDC）は、どれを選べばよいですか？
A. 社員向けに既存の業務SaaSをまとめてSSO化するならSAML、これから開発するWebサービスやスマホアプリのログインを設計するならOIDCが第一候補です。OAuth 2.0は「認可（アクセス権の委譲）」の仕組みで、ユーザーが誰であるかを保証する認証を主目的としないため、単体でSSO（ログイン）には使いません。
認証を担うのはSAMLとOIDCで、OIDCはOAuth 2.0に認証の層を足したものと整理できます。
Q. SAMLには2.0と1.xがありますが、どちらを使えばよいですか？
A. これから導入するなら、SAML 2.0を選べば問題ありません。現在、企業向けSSOの中心として広く使われ、対応するIDaaS製品やSaaSが揃っているのはSAML 2.0です。SAML 1.xは古い世代の規格で、新規に採用する理由はほとんどありません。本記事で解説したSP-Initiated／IdP-Initiatedの2つのフローも、SAML 2.0が両方に対応しています。
Q. SAML認証は安全ですか？
A. SAML自体は電子署名の検証とTLSによる通信の保護で安全性を確保できますが、認証をIdPに集約する以上、IdPが乗っ取られると連携する全SaaSに影響が及ぶ単一障害点リスクがあります。
IdP側で多要素認証（MFA）や条件付きアクセスを適用して守りを固めることが、実用上の安全性を担保する鍵になります。あわせて、IdPが停止するとすべての連携SaaSにログインできなくなるため、IdPの可用性（止まらない設計）も確認しておきましょう。
Q. SAMLに対応していないSaaSはどう管理すればよいですか？
A. 多くのIDaaSは、IdPがID・パスワードを安全に預かって自動入力する代理認証（フォーム認証型）やリバースプロキシ型の方式で、SAML非対応のSaaSもSSOに近い形でカバーできます。ただし対応できる方式はIDaaS製品ごとに異なるため、自社で使う非対応SaaSが対象かは導入前に確認が必要です。
あわせて、SCIMによるアカウント同期や利用状況の棚卸しを運用に組み込み、退職者アカウントの停止漏れを防ぐ設計にしておくと安心です。
Q. SAML認証の導入に専門知識は必要ですか？
A. IdPとして提供されているIDaaSを使えば、SAMLの詳しい仕様を理解していなくても比較的スムーズに導入できます。多くのIDaaSは主要なSaaSとの連携設定をテンプレートとして用意しているためです。ただし、属性情報のマッピングや、証明書・多要素認証を含む運用ルールの設計には一定の知識が求められるため、不安がある場合はベンダーの導入支援を活用するとよいでしょう。
Q. SAML（SSO）の導入で起こりやすいトラブルは何ですか？
A. よく挙げられるのは、IdPの電子証明書の期限切れによる一斉ログイン障害と、退職者アカウントの停止漏れの2つです。証明書は有効期限が切れると全連携SaaSでログインできなくなるため、期限管理が欠かせません。アカウントの停止漏れはSCIMによる自動同期で防げます。あわせて、設定を理解する担当者を複数名置いておくと、属人化による障害を避けられます。
SAML対応IDaaSの料金・資料を一括チェック
MCB FinTechカタログでは、SAML認証でSaaSのSSOを実現するIDaaS・ID管理システムの最新資料を無料で一括請求できます。SSO・多要素認証・SCIM対応・料金プランをまとめて比較できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
