社内で利用するSaaSが10を超えたあたりから、ID・パスワードの管理コストが業務時間を圧迫し、退職者の権限剥奪に丸1日かかる現場も珍しくありません。

しかしSSO（シングルサインオン）の実現方式は複数あり、「SAML認証」という言葉だけ聞いても自社で導入すべきか判断できないという声を多く耳にします。OAuthやOpenID Connectとの違いが曖昧なまま製品選定に入ると、後工程で技術要件が合わず差し戻しになる事例も見てきました。

本記事ではSAML認証の仕組みをアサーションのXML構造から解説し、OAuth・OpenID Connectとの違い、対応IDaaS9製品の比較、SaaS管理プラットフォームとの連携までを一気に整理します。

認証統合の旗振り役を担う情報システム部門・セキュリティ担当の方を主な読者として想定しています。

SAMLとは

SAML（読み方は「サムル」）とはSecurity Assertion Markup Languageの略で、異なるドメインに属するサービス間でユーザー認証情報を安全に受け渡しするためのXMLベースの標準規格です。OASIS（構造化情報標準促進協会）が策定しており、企業内のシングルサインオン基盤として広く採用されています。

SAMLが生まれた背景と歴史

SAMLが標準化されたのは2002年で、現在主流のSAML 2.0は2005年に正式リリースされました。当時はクラウドサービスが本格普及する前夜で、社内システムとパートナー企業のサービス間で認証情報をやり取りする手段が標準化されていなかった時期にあたります。

XMLによる電子署名と暗号化を組み合わせた構造を採用したことで、ドメインを越えた信頼関係を技術的に表現できるようになり、その後のクラウド普及期にSSO基盤として一気に存在感を増しました。

SAML 2.0 と SAML 1.x の違い

現在のエンタープライズ用途で使われるのはSAML 2.0系で、SAML 1.xは互換性がないため新規採用の対象にはなりません。SAML 2.0ではIdP-InitiatedとSP-Initiatedの両フローが標準化され、シングルログアウトやメタデータ交換も仕様に含まれています。

新規導入を検討する場合は2.0準拠であることを必ず確認しておきましょう。

なぜ今SAMLを学ぶ必要があるのか

クラウドファースト戦略を取る企業が増え、業務SaaSの数が部門単位で増えたことで、認証統合の優先度が上がっています。SaaS管理規模が50を超える組織では、IdPによる認証集約なしでは退職処理や監査対応が手作業で破綻しやすく、その中核プロトコルとしてSAMLの理解が事実上必須になっています。

参考：OASIS Security Services TC

SAML 認証の仕組み（IdP・SP・Userの3者関係とフロー）

SAML認証は認証情報を発行する側のIdP、サービスを提供する側のSP、利用者であるUserの3者でやり取りされ、IdPが発行する電子署名付きのアサーションをSPが検証することで認証が成立します。役割分担と信頼関係構築のメカニズム、そして実際の認証フロー2パターンまでを順に整理します。

Identity Provider（IdP）の役割

IdPはユーザーのアカウントとパスワードを保有し、認証処理を実行するサーバーです。Microsoft Entra ID（旧Azure AD）やOkta、Google Cloud Identityなどが代表例にあたります。多要素認証や条件付きアクセスといった追加のセキュリティ制御もIdPに集約されるため、認証ポリシーの一元管理が可能になります。

Service Provider（SP）の役割

SPは利用者にサービスを提供するアプリケーション側です。Salesforce、Slack、Boxといった業務SaaSがこの位置に立ち、IdPから受け取ったアサーションを検証してログインを許可します。SP自身はパスワードを保持しないため、漏えいの影響範囲を最小化できる構造になっています。

メタデータ交換による信頼関係の確立

SAMLでは事前にIdPとSPが「メタデータ」と呼ばれるXMLファイルを交換し、お互いのエンドポイントURL・公開鍵証明書・対応バインディングを登録することで信頼関係を構築します。このメタデータ交換が完了して初めて、後続のアサーション署名検証が機能するようになります。

設定変更や証明書ローテーションが発生した際にメタデータの再交換を忘れると、突然認証が通らなくなる事故につながるため、運用手順としてカレンダーに組み込んでおくことが推奨されます。

SAMLアサーションの中身

SAMLアサーションには3種類のStatementを含めることができます。1つ目は「いつ・誰を・どの方法で認証したか」を記述する認証Statement、2つ目はメールアドレスや所属部署などのユーザー属性Statement、3つ目は特定リソースへのアクセス可否を伝える認可決定Statementです（すべてが必ず含まれるわけではなく、用途に応じて選択されます）。

実際のアサーションは次のようなXML構造で送信されます。

<saml:Assertion ...>

  <saml:Subject>

    <saml:NameID>user@example.com</saml:NameID>

  </saml:Subject>

  <saml:AuthnStatement AuthnInstant="2026-05-01T13:00:00Z">

    <saml:AuthnContext>

      <saml:AuthnContextClassRef>

        urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

      </saml:AuthnContextClassRef>

    </saml:AuthnContext>

  </saml:AuthnStatement>

  <saml:AttributeStatement>

    <saml:Attribute Name="email">...</saml:Attribute>

  </saml:AttributeStatement>

</saml:Assertion>

XML署名により改ざんを検知できる仕組みになっており、SPは公開鍵で署名を検証してから認証を受け入れます。

SP-Initiated SSO（SP起点フロー）

SP-Initiatedは、ユーザーが最初にSPのURLへアクセスする形で認証が始まるフローで、SaaSのログインボタンを押した瞬間にIdPへリダイレクトされる動作パターンです。現代のSaaS利用ではSP-Initiatedが主流であり、メールやチャットに記載されたディープリンクから直接特定SaaSのページに飛ぶ運用との相性も優れています。

実際の流れは次のとおりです。

• ユーザーがSPのログイン画面にアクセスする
• SPがSAMLリクエストを生成し、ユーザーをIdPにリダイレクトする
• IdPが認証情報を確認し、SAMLレスポンス（アサーション）を発行する
• ユーザーはSPに戻り、アサーション検証を経てログインが完了する

IdP-Initiated SSO（IdP起点フロー）

IdP-Initiatedは、ユーザーが先にIdPのポータル画面でログインし、そこからアプリケーション一覧を選んでSPへ移動するフローです。社内ポータルから業務SaaSへの導線を一本化したい組織で採用されています。

ただしSPに直接アクセスするケースには対応できないため、SP-Initiatedと併用するハイブリッド構成が現実解になります。新規導入の場合、SP-Initiatedを基本としつつ、社内ポータル運用が前提ならIdP-Initiatedも有効化する構成が安全です。

参考：SAML 2.0 Technical Overview - OASIS

参考：SAML認証の処理のフローを知りたい - IIJ

SAML と SSO・OAuth・OIDC の違い

SAMLは企業内SSOを実現する認証規格、OAuth 2.0は権限委譲のための認可規格、OpenID ConnectはOAuth上に認証層を追加した現代的な仕様で、それぞれ目的が異なります。読者が混同しやすい3つの違いを目的・データ形式・利用シーンの3軸で整理します。

SAMLとSSOの関係

SSOは一度のログインで複数サービスを利用できる仕組みという目的を指す言葉で、SAMLはそれを実現する代表的な手段です。SSOには他にもエージェント方式や代理認証方式があり、SAMLはクラウドSaaSとの連携を前提にした標準規格として位置づけられます。

SAMLとOAuth 2.0の違い

SAMLが認証（ユーザーが本人であることの確認）のためのプロトコルなのに対し、OAuth 2.0は認可（リソースへのアクセス権限の委譲）のためのプロトコルです。

代表例で考えると、外部サービスにGoogleカレンダーへのアクセス権限を渡す処理はOAuth、Googleアカウントで業務SaaSにログインする処理はOpenID Connect、社内のSlackにEntra IDからログインする処理はSAMLという棲み分けになります。

SAMLとOpenID Connectの違い

OpenID ConnectはOAuth 2.0をベースに認証機能を加えた仕様で、データ形式にJSON Web Token（JWT）を採用しています。XMLベースのSAMLよりも軽量で、モバイルアプリやSPA（Single Page Application）との相性に優れています。

一方でSAMLは2005年から運用されてきた歴史があり、エンタープライズ向けSaaSの対応範囲が広いという強みがあります。新規開発のWebアプリならOpenID Connect、既存の業務SaaSとの統合ならSAMLという選び方が、現場の実装感覚に近い判断軸です。

参考：OpenID Connect、OAuth、SAMLの違いと用途とは？ - Okta

SAML 認証を導入するメリットとデメリット

SAML認証の導入には、利便性向上やセキュリティ強化といった明確なメリットがある一方で、IdPの単一障害点リスクや非対応SaaSの存在といった構造的な課題もあります。両面を理解したうえで設計判断する必要があります。

SAML 認証のメリット

SAML認証を導入すると、ユーザー体験・運用負荷・セキュリティ統制の3軸で効果が表れます。情シス部門からは「退職処理が数分で完了するようになった」「パスワードリセット問い合わせが半減した」といった声も多く届きます。具体的な利点は次の4点に整理できます。

• 利用者が覚えるパスワードを1つに集約できる
• SaaSごとのログイン作業がなくなり業務効率が上がる
• 多要素認証や条件付きアクセスをIdPで統一して適用できる
• IdPでアカウントを無効化すると、以後の新規認証を停止できる（既存セッションの残存には別途SLO対応やSCIMデプロビジョニングが必要）

特に最後の即応性は、SaaSが数十〜数百単位で導入されている企業ほど効果が大きく、退職処理に1日かかっていた工数が数分で完了するケースもあります。

SAML 認証のデメリット

便利さの裏側には構造上の弱点もあります。IdPに認証を集約するモデルだからこそ生まれるリスクがあり、運用設計の段階で対策を組み込んでおく必要があります。注意すべき欠点は次の3点です。

• IdPが停止すると連携する全SaaSにログインできなくなる単一障害点リスクがある
• 古いSaaSや小規模SaaSはSAML対応していないことがある
• メタデータ交換・証明書管理・属性マッピングなど初期設定が複雑になる

特にIdP障害時の影響範囲は事前にBCP（事業継続計画）に組み込み、ローカルアカウントの緊急退避経路を残しておくことが推奨されます。

SCIMとの併用が必要な理由

SAMLは認証情報の受け渡しを担いますが、ユーザーアカウントの作成・更新・削除といったプロビジョニング処理は対象外です。退職者がIdPで無効化されても、SP側のアカウントが残ったままだと監査ログに不要なアカウントが滞留し、ライセンス費用の無駄遣いにもなります。

実務ではSCIM（System for Cross-domain Identity Management）と組み合わせ、人事システムの異動データをトリガーにIdPからSPへアカウントの作成・属性更新・削除を自動化するのが一般的です。SAMLが「認証の標準」、SCIMが「ID同期の標準」と覚えておくと役割分担が整理できます。

参考：SAML認証とは？仕組みやメリットデメリットを徹底解説 - GMOセキュリティ24

ジョーシスのプラットフォームを使えば、SAML対応SaaSと非対応SaaSの両方を統合管理できます。資料ダウンロードは5分でわかるJosysからどうぞ。

SAML 認証に対応した主要IDaaS製品9選

自社でSAML認証を導入する場合、ゼロからIdPを構築するよりも、IDaaS（Identity as a Service）製品を採用する方が現実的です。グローバル6製品と国産3製品の合計9製品を、特徴と公式情報源とともに紹介します。

Microsoft Entra ID（旧 Azure AD）

Microsoft Entra IDは世界的に最も普及しているクラウドIDaaSの1つで、Microsoft 365との統合が前提の組織で多く採用されます。SAML 2.0アサーションの発行とP1以上で条件付きアクセスを利用可能で、ハイブリッドAD環境にも対応している点が支持されています。

参考：Microsoft Entra ID を使用した SAML 認証 - Microsoft Learn

Okta

Oktaは8,000以上のアプリ統合カタログを持つIDaaSで、SAMLとOpenID Connectの両方に強く、SaaS連携の網羅性で他社をリードしています。エンタープライズ規模で複数クラウドを横断する組織から長く支持されてきました。

参考：Okta Single Sign-On

OneLogin（One Identity）

OneLoginはサイバネットシステムが日本展開を手掛けるIDaaSで、SAMLによるSSOを月額2ドル前後の低価格帯から提供しています。中堅企業の最初のIDaaS採用先として選ばれるケースが多い製品です。

参考：OneLogin - サイバネット

Auth0

Auth0は開発者向けの拡張性に優れたIDaaSで、SAMLに加えカスタム認証フローの実装にも柔軟に対応します。自社プロダクトに認証基盤を組み込みたいSaaSベンダーやアプリケーション開発組織で多く採用されています。

参考：Auth0 SAML 認証

Google Cloud Identity

Google Cloud IdentityはGoogle Workspace利用組織向けのIDaaSで、SAMLによるサードパーティSaaSへのSSOを標準提供します。Workspace導入企業が追加投資なしで認証基盤を整備できる点が選定理由になります。

参考：Cloud Identity の概要 - Google Cloud

Ping Identity

Ping Identityはエンタープライズ向けに特化したIDaaSとIGAのベンダーで、大規模なSAML連携と高度なアクセス制御に定評があります。金融や通信といったミッションクリティカルな業界で多くの採用実績が見られます。

参考：Ping Identity SAML

HENNGE One

HENNGE OneはHENNGE株式会社が提供する国産IDaaSで、Microsoft 365・Google Workspace連携と日本語サポートに強みがあります。国内導入実績が豊富で、SAMLとメールセキュリティを統合的に運用できる点が中堅企業の支持を集めています。

参考：HENNGE One

IIJ ID Service

IIJ ID Serviceは株式会社インターネットイニシアティブが提供する国産IDaaSで、SAML認証とAD連携、多要素認証を組み合わせた統合認証基盤として国内企業に導入されています。通信事業者ならではの可用性設計が特徴です。

参考：IIJ IDサービス

GMOトラスト・ログイン

GMOトラスト・ログインはGMOグローバルサインが提供する国産IDaaSで、累計導入社数10,000社以上、対応アプリ8,500以上の規模を持ちます。中堅・中小企業向けの低価格プランが用意されており、初めてIDaaSを導入する組織に選ばれています。

参考：GMOトラスト・ログイン

SAMLに関する重要用語集

SAMLの仕様書や製品ドキュメントを読み進めると、特有の専門用語が登場します。実装や設定の現場で頻出する6つの用語を、初学者にも追えるように整理します。

メタデータ

メタデータはIdPとSPがお互いを認識するためのXMLファイルで、エンドポイントURL・公開鍵証明書・対応バインディングなどの設定情報がまとまっています。SAML連携の初期設定はメタデータをアップロードし合うことで完了します。

バインディング

バインディングはSAMLメッセージをHTTP上でどのように送受信するかを定義する方式で、HTTP-RedirectとHTTP-POSTが代表的です。アサーションのサイズや署名の有無に応じて使い分けます。

シングルログアウト（SLO）

シングルログアウトは1つのSPからログアウトすると、IdPと連携する他のSPからも一斉にログアウトする機能です。便利な一方で全SPで足並みを揃える必要があり、実装難度は高めになります。

X.509 証明書

X.509はSAMLアサーションの署名検証に使われる公開鍵証明書の標準規格です。証明書の有効期限切れがSAML連携停止の典型的な原因となるため、満了日のカレンダー管理が運用上の重要ポイントになります。

JIT プロビジョニング

JIT（Just-In-Time）プロビジョニングは、ユーザーが初めてSPにログインしたタイミングでアカウントを自動生成する仕組みです。SCIMによる事前プロビジョニングと比較すると軽量ですが、削除（デプロビジョニング）はカバーされない点に注意が必要です。

フェデレーション

フェデレーションは複数の組織やドメインの認証情報を相互に信頼させて連携させる概念で、SAMLはフェデレーションを実装する代表的な技術です。グループ会社間の認証統合や、社外パートナーとの限定的なアクセス連携で使われます。

参考：SAMLとは | ペンティオ

SAML 認証だけでは解決できないSaaS管理の課題

SAML認証でSSOを実現しても、SAML非対応SaaS、シャドーIT、退職者の権限剥奪、利用状況の可視化までは手が届きません。SaaSが部門単位で導入される現代では、SAMLとSaaS管理プラットフォーム（SMP）の組み合わせが運用上のスタンダードになりつつあります。

SAML非対応SaaSの存在

業務で使われるSaaSのすべてがSAML対応というわけではありません。特に部門が独自に契約したスタートアップ製SaaSや業務特化型ツールはSAMLを実装していないことが多く、IdP配下で一元管理しきれない領域が残ります。

シャドーITの可視化

情シス部門が把握していないSaaSが社内に存在するシャドーIT問題は、SAMLだけでは検知できません。誰がどのSaaSを使っているかを把握するには、SaaSへのログイン状況や購買データを横断的に取得する仕組みが必要になります。

退職者の権限剥奪と監査ログ

SAML対応SaaSはIdPでアカウントを止めれば即座にアクセスを遮断できますが、SAML非対応SaaSは個別に削除作業を行う必要があります。退職処理の漏れは情報漏えいリスクと監査指摘の双方につながり、特に上場企業では内部統制の論点になりやすい領域です。

SaaS管理プラットフォームが補う領域

ジョーシスのプラットフォームは350以上のSaaSアプリ連携と31カテゴリの管理機能を備え、SAML対応・非対応の双方を統合管理できる設計です。国内外700社以上の導入実績があり、事例によっては、IT工数の最大50%削減、IT管理コストの最大75%削減につながった報告もあります。

無料デモはJosys デモ予約から日程を選べます。

SAML認証についてよくある質問

SAML認証の導入検討フェーズで読者から多く寄せられる質問を整理しました。製品選定の前段階で迷いやすいポイントを取り上げています。

SAMLは何と読みますか

SAMLは英語の頭文字をそのまま読んで「サムル」と発音するのが一般的です。Security Assertion Markup Languageの略で、ベンダー資料や技術勉強会でも「サムル」呼びが定着しています。

SAML 2.0と1.x はどちらを使えばよいですか

新規導入はSAML 2.0一択になります。SAML 1.xは互換性がなく、対応するIDaaS製品やSaaSもほぼ存在しないため、現役で運用しているシステム以外で新規採用する理由はありません。

SAML認証は安全ですか

SAML自体は署名検証とTLS・必要に応じた暗号化により安全性を確保できますが、IdPの認証情報が漏えいすると連携する全SaaSが侵害される単一障害点リスクがあります。多要素認証や条件付きアクセスをIdP側で適用することで実用上の安全性を担保できます。

SAMLが使えないSaaSはどう管理すればよいですか

SAML非対応SaaSはIdPで認証統合できないため、SaaS管理プラットフォームで利用状況の可視化とアカウント棚卸しを行う運用が現実的です。SAMLと並行してSCIMによる自動プロビジョニング、もしくはSMP経由の手動管理で補完する設計が一般的になっています。

まとめ

SAML認証はOASISが策定したXMLベースの標準規格で、企業内SSOを実現する中核プロトコルです。IdP・SP・Userの3者構造とアサーションXMLの仕組み、SP-Initiated／IdP-Initiatedの2フロー、OAuth・OpenID Connectとの目的軸の違いを理解すれば、製品選定の解像度が一段上がります。

ただしSAMLだけでは非対応SaaSやシャドーITには手が届かないため、IDaaSとSaaS管理プラットフォームを組み合わせた運用設計が現実解です。自社のSaaS環境を可視化し、退職処理から監査対応までを統合運用したい場合は、5分でわかるJosysから検討を始めるのが近道になります。