SAML認証は、IdPが確認したユーザーの認証結果をサービス側へ渡し、シングルサインオンを実現する仕組みです。SAMLは「サムル」と読み、Security Assertion Markup Languageの略です。

OpenID Connectは認証を扱う仕様で、SAMLと目的や形式が異なります。導入時にはIdPと利用SaaSがどの方式に対応するかを確認します。

SAML非対応の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から受け取ったアサーションを検証してログインを許可します。SAMLによるログインでは、IdPの認証結果をSPが受け入れます。SP側に別のログイン方法があるかは、サービスごとに確認します。

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

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

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

SAMLアサーションの中身

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

アサーションの内容を確認するときは、認証された利用者、認証時刻、ユーザー属性を読み分けます。前述の各Statementの役割を押さえたうえで、SP側が受け取る認証結果と属性の設定を確認してください。

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

Josysを使えば、SAML対応SaaSと非対応SaaSの両方を統合管理できます。資料ダウンロードは5分でわかるJosysからどうぞ。

SAML非対応のSaaSを管理するための確認手順

SAMLに対応していないことと、認証を連携できないことは同じではありません。SAML以外の方式に対応するか、契約プランの制約があるかを確認します。そのうえで、ログインの方法とアカウントを管理する方法を分け、個別対応が必要な対象を明確にします。

認証方式とアカウント操作を別々に確認する

対象SaaSで利用できる認証方式と、アカウントの作成・更新・停止の方法を一覧化します。SAML対応だけを管理完了の条件にすると、SaaS側のアカウントやライセンスが残ることがあります。認証が連携できても、退職時の停止・削除まで確認する必要があります。

SAMLやOIDCは認証のための連携であり、SCIMはアカウント情報を同期するための仕組みです。詳細はSCIMによるSaaSプロビジョニングの仕組みで整理しています。

非対応サービスを退職処理から漏らさない

認証基盤の管理対象になっていないSaaSも、利用者と管理担当者を台帳に記録します。退職時にそのサービスを使っていたかを調べ始めるのではなく、平時の棚卸しで対象を把握することが、対応漏れを減らす出発点です。

退職処理では、IdPの無効化、SaaS側のアカウント停止、既存セッションへの対応をサービスごとに確認します。自動化の実行結果と手動対応の記録を合わせ、残存アカウントや不要な権限がないかを点検してください。SSOの設定が済んでいることだけで完了としない運用が必要です。

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へのログイン状況や購買データを横断的に取得する仕組みが必要になります。

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

IdPの無効化で新規認証を止めても、SaaS側の既存セッションやアカウントの停止・削除には別の対応が必要です。SAML非対応のSaaSも、利用できる連携と個別の操作手順を確認します。退職処理の漏れは情報漏えいリスクと監査指摘の双方につながり、特に上場企業では内部統制の論点になりやすい領域です。

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

Josysは、350以上・31カテゴリのアプリ連携に対応するAI駆動のアイデンティティセキュリティ基盤です。国内外1,000社以上に導入され、SaaSの利用把握、アカウント管理、アクセス権レビューを支援します。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双方の対応状況によります。認証連携の可否にかかわらず、利用状況の把握とアカウント棚卸しを運用に含めます。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から検討を始めるのが近道になります。