SAMLとは？SSO（シングルサインオン）を実現する仕組みと認証フロー｜OAuth・OpenID Connectとの違い、メリット・デメリットを解説

社内で利用するSaaSやクラウドサービスが増えるにつれ、サービスごとにIDとパスワードを管理する負担や、ログイン画面の乱立が課題になっています。その解決策としてシングルサインオン（SSO）の導入を検討すると、設定画面や各種の資料で必ず目にするのが「SAML」「SAML連携」という言葉です。

SAMLは、一度のログインで複数のサービスを利用できるSSOを実現する、認証情報のやり取りに関する標準規格です。ただ、仕組みや「OAuth」「OpenID Connect」といった似た用語との違いまで正確に理解しないまま、導入の検討が進んでしまうことも少なくありません。

本記事では、SAMLとは何かという結論から、IdP・SP・アサーションといった仕組み、2種類の認証フロー、OAuth・OpenID Connect・LDAPとの違い、導入のメリット・デメリットと注意点までを整理します。あわせて、自社でSSOを実現する際に選択肢となるSAML対応のサービスも紹介します。

SAMLとは？

SAML（サムル／Security Assertion Markup Language）とは、サービス間で認証に関する情報を安全に受け渡すための標準規格です。平たく言えば、一度ログインするだけで複数のクラウドサービスや社内システムを利用できるシングルサインオン（SSO）を実現するための仕組みです。

SAMLは標準化団体のOASIS（Organization for the Advancement of Structured Information Standards）が策定したもので、現在広く使われているのは2005年3月に標準化されたSAML 2.0です。

特定のベンダー独自の仕組みではなく、多くのクラウドサービスやID管理製品が対応する共通規格であるため、異なる会社のサービス同士をまたいでSSOを構成できます。

出典・参考資料（2件）

• 出典：Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0（OASIS Standard, 15 March 2005）｜OASIS（http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf）
• 参考資料：SAML V2.0 Technical Overview｜OASIS（https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html）

SAMLが実現するSSO（シングルサインオン）とは

SSO（シングルサインオン）とは、1組のIDとパスワード（または生体認証などの認証）で、複数のサービスにログインできる仕組みです。利用者はサービスごとにログインし直す必要がなくなり、管理者はアカウントを一元的に管理できます。

SSOを実現する方式にはいくつかの種類がありますが、SAMLはそのうち、会社の垣根を越えてクラウドサービスへSSOする際によく使われる方式です。SAMLが「どのサービスにログインするか」ではなく「このユーザーは認証済みである」という情報をサービス間で受け渡すことで、一度の認証が複数のサービスに効くようになります。

SAMLの仕組み（IdP・SP・アサーションの役割）

SAMLによるSSOには、「IdP」「SP」「アサーション」という3つの登場人物があります。それぞれが何をするのかを押さえると、認証フローの理解がスムーズになります。

• IdP（Identity Provider／アイデンティティプロバイダー）：利用者の情報を管理し、本人かどうかを認証する側です。認証が済んだ利用者について「この人は認証済みである」と各サービスに伝える、SSOの起点となる存在です。
• SP（Service Provider／サービスプロバイダー）：利用者が実際に使いたいサービス（Google WorkspaceやSalesforceなど）の側です。自分で認証を行う代わりに、IdPからの「認証済み」という通知を信頼してサービスへのアクセスを許可します。
• アサーション（Assertion）：IdPがSPに渡す「認証に関する情報のかたまり」です。「いつ・誰が・どの方法で認証されたか」といった内容を含み、これをSPが受け取ることでログインが成立します。

SAMLの仕様では、アサーションが伝える情報として「認証（いつ・どの手段で認証されたか）」「属性（利用者に紐づく部署やメールアドレスなどの情報）」「認可の決定（特定のリソースへのアクセスを許可するか）」の3種類が定義されています。実際のSSOでは、主に「認証」と「属性」の情報がやり取りされます。

「認可の決定」を伝える機能も規格上は定義されていますが、SAML 2.0以降は拡張されておらず、実運用ではほとんど使われません。

出典・参考資料（2件）

• 出典：Glossary for the OASIS Security Assertion Markup Language (SAML) V2.0（OASIS Standard, 15 March 2005）｜OASIS（http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf）
• 出典：Assertions and Protocols for the OASIS SAML V2.0（core, §1.2 / §2.3.3）｜OASIS（http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf）

SAMLの通信が安全とされる理由（デジタル署名）

「認証済み」という情報をサービス間でやり取りするなら、その情報が途中で偽造・改ざんされない仕組みが欠かせません。SAMLでは、アサーションにデジタル署名を付けることで、発行元が正規のIdPであること（発行者の正当性）と、内容が改ざんされていないこと（完全性）を確認できるようにしています。

特に、Webブラウザを経由してアサーションを受け渡す一般的な方式では、応答メッセージにXML Signatureによるデジタル署名を付けることが必須とされています。前提として、IdPとSPは事前に証明書（公開鍵）を交換して互いを信頼し、SPは受け取ったアサーションの署名をIdPの証明書で検証します。

加えて、通信経路の盗聴や改ざんを防ぐため、SSL/TLSによる暗号化通信の利用が推奨されています。属性情報など中身の秘匿性が求められる場合は、XML Encryptionでアサーション自体を暗号化することもできます。こうした仕組みにより、第三者が「認証済み」のふりをしてサービスに侵入することを防いでいます。

出典・参考資料（2件）

• 出典：Assertions and Protocols for the OASIS SAML V2.0（core, §2.3.3 / §5）｜OASIS（http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf）
• 出典：SAML V2.0 Technical Overview（Web Browser SSO）｜OASIS（https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html）

SAML認証のフロー（2つの方式）

SAMLによる認証は、どこを起点にログインを始めるかによって「SP-initiated方式」と「IdP-initiated方式」の2種類に分かれます。SAML 2.0はこの両方の方式に対応しています。

SP-initiated方式（利用したいサービスから始まる）

利用者が使いたいサービス（SP）に最初にアクセスする、もっとも一般的なパターンです。おおまかな流れは次のとおりです。

1. 利用者がSP（例：Salesforce）にアクセスします。
2. SPはまだ認証されていないことを確認し、利用者をIdPへ転送して認証を要求します。
3. IdPが利用者を認証します（すでにIdPにログイン済みなら、この手順は省略されます）。
4. IdPが署名付きのアサーションを発行し、利用者を通じてSPに返します。
5. SPがアサーションを検証し、問題なければサービスへのアクセスを許可します。

IdP-initiated方式（ポータル画面から始まる）

利用者が先にIdP（またはIdPが提供するポータル画面）にログインし、そこから各サービスへ移動するパターンです。社内ポータルに業務システムのアイコンが並び、クリックするだけでログインできる形をイメージするとつかみやすくなります。

1. 利用者がIdPにログインします。
2. ポータル画面から、利用したいサービス（SP）を選びます。
3. IdPが署名付きのアサーションを発行し、利用者を通じて選んだSPに渡します。
4. SPがアサーションを検証し、問題なければサービスへのアクセスを許可します。

どちらの方式でも、実際にパスワードなどで本人確認を行うのはIdPだけです。各サービス（SP）はIdPが発行したアサーションを信頼するため、サービスごとにパスワードを入力する必要がなくなります。

出典・参考資料（1件）

• 出典：SAML V2.0 Technical Overview（§3.2 / §4 Web Browser SSO）｜OASIS（https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html）

SAMLとOAuth・OpenID Connect・LDAPの違い

SAMLと混同されやすい用語に、OAuth・OpenID Connect・LDAPがあります。いずれもID・アクセス管理に関わる技術ですが、担う役割が異なります。違いを理解する鍵は、「本人確認（認証）」と「権限付与（認可）」のどちらを目的とするかです。

認証（Authentication）は「あなたが誰であるか」を確かめること、認可（Authorization）は「あなたに何を許可するか」を決めることです。たとえるなら、認証は受付で社員証を見せて本人だと確認してもらうこと、認可は確認済みの社員がどの部屋に入れるかを権限ごとに決めることにあたります。SAMLは主に認証とその情報の受け渡しを担い、OAuthは認可を担う、という役割の違いがもっとも基本的な区別になります。

※各規格・プロトコルの役割は公式仕様に基づく一般的な整理です。実際の対応範囲は製品・実装により異なります。

補足すると、OAuth 2.0は「認可のためのフレームワーク」であり、アプリが利用者に代わってサービスのデータへアクセスする権限を得る仕組みです。それ自体は「誰であるか」を確かめる認証の仕組みではありません。そのOAuth 2.0の上に本人確認の層を加えたものがOpenID Connectで、近年のWebサービスのログインで広く使われています。

LDAPは、社内のユーザー情報を集めた台帳（ディレクトリ）にアクセスするためのプロトコルで、Active Directoryなどで利用されます。SAML・OAuth・OpenID Connectが「サービスをまたいで認証・認可の情報を受け渡す」のに対し、LDAPは「ディレクトリに問い合わせる」別の階層の技術です。

クラウドサービスへのSSOでは、社内のディレクトリ（Active DirectoryなどをLDAPで参照）を認証元としつつ、外部のSaaSとの連携にはSAMLを使う、といった組み合わせもよく見られます。利用者情報は社内の台帳で一元管理し、その認証結果をSAMLでクラウドサービスへ引き渡す構成です。

出典・参考資料（3件）

• 出典：RFC 6749「The OAuth 2.0 Authorization Framework」｜IETF（https://datatracker.ietf.org/doc/html/rfc6749）
• 出典：OpenID Connect Core 1.0｜OpenID Foundation（https://openid.net/specs/openid-connect-core-1_0.html）
• 出典：RFC 4511「Lightweight Directory Access Protocol (LDAP): The Protocol」｜IETF（https://datatracker.ietf.org/doc/html/rfc4511）

SAMLを導入するメリット・デメリット

SAMLによるSSOは利便性とセキュリティの両面で効果がありますが、単一の認証に集約することによる注意点もあります。導入の可否を判断するために、両面を押さえておきましょう。

メリット

• 利用者の利便性が高まる：一度の認証で複数のサービスを使えるため、サービスごとのログインやパスワードの覚え直しが不要になります。
• セキュリティを強化できる：認証をIdPに集約することで、パスワードの使い回しや単純なパスワードといったリスクを抑えられます。IdP側で多要素認証を一括して適用することも可能です。
• 管理者の負担を軽減できる：アカウントの発行・停止をIdPで一元管理できるため、退職者のアカウント停止漏れやサービスごとの個別対応を減らせます。

デメリットと緩和策

デメリットは、裏を返せば「認証を1か所に集約する」ことに由来します。導入可否を判断するうえで、次の点と緩和策を対で押さえておきましょう。

• SAMLに対応していないサービスがある：SSOでまとめたいサービスがSAMLに対応していない場合、そのサービスは個別のログインが残ります。対応状況を事前に確認し、SAML以外の連携方式（OpenID Connectやフォームベース認証など）も備える製品を選ぶことで補えます。
• IdPが停止すると影響が大きい：認証の起点であるIdPに障害が起きると、連携する複数のサービスにログインできなくなります。IdPの可用性（稼働率）を確認し、重要なサービスには代替のログイン手段を用意しておくことがリスクの備えになります。
• 認証情報が漏れた際の影響が広がる：1組の認証情報で複数サービスに入れるということは、その情報が漏れた場合に影響が広範囲に及ぶということです。多要素認証（MFA）を併用し、パスワードだけに頼らない認証にすることで、漏えい時の被害を抑えられます。

併用する多要素認証（MFA）について、認証方式ごとの違いや自社に合う選び方を詳しく知りたい方は、認証方式・料金別に比較した以下の記事が参考になります。

SAML導入で失敗しないための注意点

デメリットを踏まえたうえで、実際の導入でつまずきやすいポイントを具体的に挙げます。

• IdP障害時の運用を決めておく：IdPに障害が起きたときの連絡体制や、サポート窓口の対応時間（24時間対応か、平日日中のみか）を導入前に確認することが重要です。稼働率の保証（SLA）の有無も、重要業務を預けるかどうかの判断材料になります。
• 連携数の上限と追加費用を確認する：1契約で連携できるサービス数の上限や、連携を増やす際の追加費用は製品ごとに異なります。いま使っているサービスだけでなく、今後増やす予定のものも含めて試算しておくと、導入後の想定外のコストを避けられます。
• 設定ミスを防ぐ：SAMLの連携では、IdPとSPの双方で証明書やアサーションの設定を正しく行う必要があります。特に、利用者を識別するNameIDの形式や、メールアドレス・部署といった属性の項目名がIdPとSPで食い違うのは典型的なつまずきです。この場合、IdP側の認証自体は成功してもSP側でログインに失敗します。設定を誤ると認証が通らなかったり、意図しないアクセスを許したりする原因にもなるため、設定画面の分かりやすさや、導入時のサポートの手厚さも確認しておくとよいでしょう。

SAMLに対応したSSO／IDaaSで自社のSSOを実現する

自社でSAMLによるSSOを実現するには、IdPの役割を担うサービスが必要です。この役割を提供するのが、SSO・多要素認証・ID管理をまとめて提供するIDaaS（Identity as a Service）と呼ばれるクラウドサービスです。国産のIDaaS、グローバルに展開するIDaaS、オープンソースで自前構築する方式など、実現の手段には幅があります。

選び方や導入事例まで含めてIDaaS全体をじっくり比較検討したい方は、おすすめサービスと選定のポイントを詳しく解説した以下の記事もあわせてご覧ください。

ここでは、SAML 2.0に対応し、複数のクラウドサービス・社内システムへのSSOを実現するサービスを、以下の比較表で紹介します。まず「提供形態」の列で、国産IDaaS・グローバルIDaaS・OSS（自前構築）のどれに当たるかを見ると、自社の運用体制に合う候補を絞り込みやすくなります。表中の「プロビジョニング」は、アカウントの自動作成・停止といったID管理の自動化を指します。

※料金・機能は2026年10月時点の各社公開情報に基づく整理です。料金は税区分・課金単位が各社で異なります。最新の対応範囲・価格は各社公式サイト・資料でご確認ください。

ここでは一例として、SSO・多要素認証・ID管理を統合して提供するCloudGate UNOを取り上げます。各サービスの詳細は上記の比較表と各社の公式資料を、全体の比較や選び方は先ほどのIDaaS比較記事をあわせてご覧ください。

CloudGate UNO（株式会社インターナショナルシステムリサーチ）

CloudGate UNOは、株式会社インターナショナルシステムリサーチ（ISR）が自社開発する、ゼロトラストの考え方に基づくSSO・多要素認証・アクセス制限・ID管理を統合した国産のIDaaSです。

IdPとして、SAML 2.0・OpenID Connect・フォームベース認証に対応し、Google Workspace・Microsoft 365・Salesforce・Slackなど多数のクラウドサービスへのSSOを実現します。

特徴は、端末・場所・時間の3つの軸で設定できるアクセス制限と、フィッシング攻撃に強いパスキー（FIDO2）によるパスワードレス認証です。パスキー認証は上位プラン限定ではなく、全プラン・全ユーザーで利用できます。

契約数は1,400社以上で、直近1年間で1億回以上の認証実績と99.99%の稼働率があり、ISMS（ISO/IEC 27001、登録番号IS 676799）も取得しています。

料金はStandard Plusが月額400円、Enterprise Plusが500円、Smart Packが600円（いずれも1ユーザーあたり税抜）で、30日間の無料トライアルが用意されています。

出典・参考資料（2件）

• 出典：料金プラン｜CloudGate UNO（https://www.cloudgate.jp/price）
• 出典：サービスの信頼性（認証実績・稼働率）｜CloudGate UNO（https://www.cloudgate.jp/service-reliability）

まとめ

SAMLは、サービス間で認証情報を安全に受け渡し、一度のログインで複数サービスを使えるSSOを実現する標準規格です。IdP・SP・アサーションという3つの登場人物が連携し、デジタル署名によって「認証済み」という情報の正当性が担保されます。

SAMLは認証とその受け渡し、OAuthは認可、OpenID ConnectはOAuthに認証を加えたもの、LDAPはディレクトリへの問い合わせ、と役割を整理すると、それぞれの違いも見通しやすくなります。

SAMLによるSSOは利便性とセキュリティの両面で効果がある一方、認証をIdPに集約するがゆえの注意点もあります。多要素認証の併用やIdPの可用性確認といった備えを押さえたうえで、自社の利用サービスに合ったSAML対応のIDaaSを選び、安全なSSO導入を進めてください。

よくあるご質問（FAQ）

Q. SAMLとは何ですか？

A. SAMLは、サービス間で認証情報を安全に受け渡し、一度のログインで複数のサービスを使えるSSO（シングルサインオン）を実現する標準規格です。正式名称はSecurity Assertion Markup Languageで、標準化団体OASISが策定し、現在はSAML 2.0が広く使われています。

特定のベンダー独自の仕組みではなく、多くのクラウドサービスやID管理製品が対応する共通規格のため、会社をまたいだSSOを構成できます。

Q. SAMLとSSOの違いは何ですか？

A. SAMLとSSOの違いは、SSOが「一度のログインで複数サービスを使える」という仕組み（目的）そのものを指すのに対し、SAMLはそのSSOを実現するための具体的な方式の一つである点です。SSOを実現する方式はSAMLのほかにもありますが、会社の垣根を越えてクラウドサービスへSSOする場面では、SAMLがよく使われます。

Q. SAMLとOpenID Connectはどちらを選べばよいですか？

A. 企業システムや業務用クラウドサービスのSSOにはSAML、WebやモバイルアプリのログインやソーシャルログインにはOpenID Connectが向いています。OpenID ConnectはOAuth 2.0に認証を加えた比較的新しい規格です。実際にどちらを使うかは、連携したいサービス側が対応している方式によって決まる場合が多いため、まずは対象サービスの対応状況を確認するとよいでしょう。

Q. SAMLはどんな場面で使われますか？

A. SAMLは、Google Workspace・Microsoft 365・Salesforceなど、複数のクラウドサービスや社内システムへ一度のログインでアクセスする企業のSSOで主に使われます。利用者のログインやパスワード管理の手間を減らすと同時に、管理者がアカウントを一元管理し、退職者のアカウント停止漏れを防いでセキュリティを高めたい場面で選ばれます。

Q. SAMLの導入・実装は難しいですか？

A. SAMLの導入自体は、SAML 2.0に対応したIDaaS（SSOサービス）を使えば、専門的な開発なしに設定で実現できます。ただし、IdPとSP（利用するサービス）の双方で証明書やアサーションの設定を正しく行う必要があり、設定を誤ると認証が通らなかったり、意図しないアクセスを許したりする原因になります。

設定画面の分かりやすさや、導入時のサポートの手厚さを製品選定時に確認しておくことが重要です。

Q. SAMLは無料で使えますか？

A. SAMLという規格自体は公開された標準仕様のため、規格を使うこと自体に費用はかかりません。ただし、実際にSSOを構築するにはIdPの役割を担うIDaaSなどのサービスが必要で、多くは1ユーザーあたり月額数百円程度の利用料がかかります。無料トライアルを用意している製品もあるため、本格導入の前に使い勝手を試すこともできます。

Q. SAML 2.0とSAML 1.xの違いは何ですか？

A. 現在の主流はSAML 2.0で、SSOの標準規格として広く使われています。SAML 1.x（1.0／1.1）は2.0以前の旧バージョンで、SP-initiatedとIdP-initiatedの両方式への対応など機能が拡充された2.0に置き換わりました。これから導入する場合は、連携したいサービスやIDaaSがSAML 2.0に対応しているかを確認すれば十分です。

Q. SSOを導入すればクラウドのセキュリティ対策は十分ですか？

A. SSOの導入だけでは十分とはいえず、多要素認証（MFA）の併用が重要です。SAMLによるSSOは1組の認証情報で複数サービスに入れるため、その情報が漏れた場合の影響が広範囲に及びます。IdP側でMFAを一括して適用し、パスワードだけに頼らない認証にすることで、漏えい時の被害を抑えられます。

IdPに障害が起きると連携サービスへ一斉にログインできなくなる点も踏まえ、重要なサービスには代替のログイン手段を用意しておくことが望ましいでしょう。

SSO・IDaaSの料金・資料を一括チェック

MCB FinTechカタログでは、SAMLに対応したSSO・IDaaSの最新資料を無料で一括請求できます。対応する認証方式・連携できるサービス・料金・サポート体制など、比較に必要な情報をまとめて確認できます。

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

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