SAMLとは？認証フロー・IdP/SPの仕組みとOAuth・OIDCとの使い分けを実装視点で解説

SAML（Security Assertion Markup Language）は、IdP（IDプロバイダ）とSP（サービスプロバイダ）の間でXML形式の認証情報をやり取りし、シングルサインオン（SSO）を実現する標準規格です。この記事では、SAML 2.0のアサーション構造、SP-Initiated／IdP-Initiatedの認証フロー、HTTP-POSTなどのバインディング、署名・暗号の検証、そしてOAuth 2.0・OIDCとの責務の違いと使い分けまでを、実装者が設計判断できる粒度で整理します。自社サービスへ社内IdPを連携させる担当者や、SAML対応を製品に組み込む開発者が対象です。

まとめ：SAMLはXMLで認証と認可を運ぶSSO標準と実装の要点

SAMLは、認証を担うIdPが署名付きのXMLアサーションを発行し、SPがその署名を検証してログインを成立させるプロトコルです。現行の主流はOASISが2005年に承認したSAML 2.0で、Web Browser SSO Profileが企業SSOの中心となっています。SPが起点となるSP-Initiatedフローが基本形で、IdPのポータルから起動するIdP-Initiatedは経路が短い反面、リプレイやCSRFへの備えを自前で設計する必要があります。

プロトコル選定の勘所は責務の切り分けにあります。SAMLは認証と属性連携をXMLで運び、OAuth 2.0はアクセス権限の委譲（認可）を担い、OIDCはそのOAuth 2.0の上にJWTで認証層を足したものです。新規のSPAやモバイルアプリならOIDCが扱いやすく、既存の業務システムや社内IdPがSAML前提であればSAMLを選びます。実装ではアサーションの署名検証・有効期限・オーディエンス制限の3点を外すと、なりすましログインの穴になります。

SAMLの基本構造とIdP・SP・アサーションが担う認証の役割分担

SAMLを理解する近道は、登場する3者と、その間で渡される「アサーション」というXML文書の役割を押さえることです。プロトコルの中身は複雑ですが、信頼の流れ自体は単純な構図になっています。

IdP・SP・プリンシパルの3者とメタデータ交換で結ぶ信頼関係

SAMLには3つの登場人物がいます。認証情報を管理し身元を保証するIdP（Identity Provider）、ユーザーに機能を提供するSP（Service Provider）、そして両者を利用する本人であるプリンシパル（ユーザー）です。SPは自前でパスワードを持たず、「このユーザーは確かに本人だ」という判断をIdPに委ねます。

この委任が成り立つ前提が、IdPとSPの事前の信頼関係です。両者はentityIDと署名用の公開鍵証明書を含むメタデータXMLを交換し、相手を識別できる状態を先に作ります。信頼を結んでいないIdPからのアサーションをSPが受け付けないことが、SAMLの安全性の土台になります。

SAMLアサーションの3種類と署名・宛先・有効期限で守る中身

アサーションはIdPが発行するXML文書で、SPに渡す「保証書」にあたります。仕様上は3種類が定義されています。ログインの事実を伝える認証アサーション、氏名や部署・権限などを伝える属性アサーション、特定リソースへのアクセス可否を伝える認可決定アサーションです。企業SSOで中心となるのは認証アサーションと属性アサーションの2つになります。

アサーションにはXML Signatureによる電子署名が付き、SPは署名を検証して改ざんの有無を確かめます。加えて、宛先を縛るAudience制限、受信者を指定するRecipient、有効期限を示すNotOnOrAfterが含まれます。ここを検証しないと、別SP向けのアサーションを使い回されかねません。ユーザーを識別する識別子はNameID要素に入り、永続IDやメールアドレス形式など、SP側の要件に合わせて形式を決めます。

SAML認証フローの実装：SP-InitiatedとIdP-Initiatedの経路差

SAMLの認証フローは、どちらが起点になるかで2系統に分かれます。実装では、この経路差とブラウザ経由での受け渡し方法（バインディング）の選択が、そのまま設計上の判断ポイントになります。

SP-Initiated SSOのリダイレクトから戻りまでの5工程

もっとも使われるのがSP-Initiated方式です。ユーザーが未ログインでSPにアクセスすると、SPはSAMLRequestを生成してブラウザをIdPへリダイレクトさせます。IdPはログイン画面を出して本人確認を行い、認証が済むと署名付きのSAMLResponseをブラウザ経由でSPへ戻す仕組みです。SPは署名と各種条件を検証し、問題なければセッションを張ってログインを完了させます。処理の順序は次のとおりです。

1. ユーザーがSPの保護されたページへアクセスする
2. SPが認証要求を作りブラウザをIdPへ転送する
3. IdPがログイン画面で本人を認証する
4. IdPが署名付きレスポンスをSPへ返す
5. SPが署名を検証しセッションを確立する

この方式はSP側でアクセス先が確定しているため、ログイン後に本来行きたかったページへ戻す制御が組みやすい特性があります。

IdP-Initiated方式との経路差とリプレイ対策の注意点

IdP-Initiated方式では、ユーザーが先にIdPのポータルにログインし、そこに並ぶアプリのアイコンからSPへ飛びます。IdPはSPからの要求を待たずにアサーションを送り込むため、経路は短くなります。一方でSPは「頼んでいないログイン」を受け取る形になり、SAMLRequestと突き合わせた検証ができません。

この非対称さがリスクの温床です。盗まれたアサーションを再送されるリプレイ攻撃や、意図しないSPへのログインを誘発されるおそれがあるため、IdP-Initiatedを許可する場合はアサーションの一意ID（ID属性）の使い回し検知と、短い有効期限の設定が前提になります。社内ポータルからの導線を優先したい場面を除けば、まずSP-Initiatedを基本に据える設計をおすすめします。

HTTP-Redirect・HTTP-POSTバインディングとメタデータ交換

SAMLメッセージをブラウザで運ぶ手段を「バインディング」と呼びます。実装で使うのは主に2つです。要求を送る往路にはURLへ載せるHTTP-Redirectバインディング、署名付きレスポンスを返す復路にはフォーム自動送信のHTTP-POSTバインディングを使うのが定番の組み合わせになります。

復路にHTTP-POSTを使うのは、署名付きレスポンスがURL長の制限を超えやすいためです。SPが応答を受け取るエンドポイントはメタデータ内のAssertion Consumer Service（ACS）として宣言し、IdPはそこにだけレスポンスを返します。IdPとSPはこのメタデータを交換して初期設定を済ませ、証明書更新時にも同じ仕組みで鍵を切り替えます。

SAMLとOAuth 2.0・OIDCの違いを認証と認可の境界で使い分け

SAMLの設計判断で必ず突き当たるのが、OAuth 2.0・OIDCとの棲み分けです。3者は似た文脈で語られますが、担う責務が異なります。ここを取り違えると、認可の仕組みで認証を代用してしまう典型的な設計ミスにつながります。

SAML・OAuth 2.0・OIDCの責務とデータ形式の比較

3者の違いは「何を運ぶか」で整理できます。SAMLは認証と属性をXMLで運ぶ規格、OAuth 2.0（RFC 6749）はアクセス権限の委譲を担う認可の枠組み、OIDCはそのOAuth 2.0の上に載せた認証層でJWTを使います。OAuth 2.0単体は「誰か」を保証する仕組みではないため、ログイン用途に流用すると本人性の担保が弱くなる点に注意が必要です。

それぞれの詳細な仕組みは個別記事で扱っています。認可フローとトークンの取り回しはOAuth 2.0とは？仕組み・認可フローと認証・認可の違いをわかりやすく解説を、OAuth 2.0の上でIDトークンをどう発行するかはOIDC（OpenID Connect）とは？仕組み・OAuthとの違いをわかりやすく解説を参照してください。本記事のSAMLと合わせ、認証・認可の3規格が揃います。

SPA・モバイルと既存業務システムでプロトコルを選ぶ判断基準

選定は玉虫色にせず、条件で言い切れます。フロントとAPIが分離したSPAやスマートフォンアプリを新規に作るなら、JWTが軽くトークン運用の情報が豊富なOIDCが扱いやすい選択です。XMLの署名処理とリダイレクトを多用するSAMLは、この構成では実装コストが重くなります。

逆に、接続先の社内IdP（Active Directoryフェデレーションや既存のSSO基盤）がSAMLしか話せない場合や、SaaS側がSAML接続だけを提供している場合は、素直にSAMLを選びます。ここでOIDCに寄せようとすると、対応していないIdPとの間で追加のブリッジを自作する羽目になり、費用対効果が崩れます。既存資産がSAMLかOIDCかを先に確認することが、遠回りを避ける近道です。

SAML導入時の署名検証・シングルログアウト・採用可否の判断基準

SAMLは仕様が広く、実装の抜けがそのままセキュリティ事故に直結します。導入で押さえるべき検証項目と、採用そのものを見送るべき場面を具体的に示します。自社サービスへSSOを組み込む設計段階で、ここを判断材料にしてください。

署名・有効期限・Audience検証で外してはいけない4項目

SPの実装で最初に固めるのが検証ロジックです。IdPの署名検証を省いたり、署名アルゴリズムの検証を緩めたりすると、偽造アサーションを受け入れる致命的な穴になります。過去にはXMLの構造を悪用して署名検証を回避するXML Signature Wrapping攻撃が知られており、パーサとバリデータの実装差が突かれてきました。

実務で最低限外せない検証は次の項目です。単なる有無ではなく、値まで突き合わせます。

• IdP証明書によるXML署名の妥当性
• NotBeforeとNotOnOrAfterの有効期限
• 自SPを指すAudience制限の一致
• アサーションIDの一意性（再送検知）

これらは自作せず、実績あるSAMLライブラリに任せる判断が堅実です。言語ごとにpython3-samlやOneLogin系、Spring Security SAMLなどの実装があり、既知の攻撃への対策が織り込まれています。

シングルログアウト（SLO）とセッション有効期限の設計上の判断

ログインの裏返しとして設計が要るのがシングルログアウト（SLO）です。SAMLにはSPまたはIdPからログアウトを開始し、連携する全SPのセッションを一括で終わらせる仕組みがあります。ただしSLOは全SPが正しく応答することを前提とするため、1つのSPが応答を返さないだけで全体が中途半端な状態になりがちです。

そのため、SLOを厳密に実装するか、各SPのセッション有効期限を短めに設定して自然失効に寄せるかは、扱う情報の機微さで判断します。金融や医療のように即時失効が要る領域はSLOを作り込み、社内ツール中心なら短命セッションで運用を軽くする、という切り分けが現実的です。SP側のセッション寿命は、IdPのアサーション有効期限と整合させておきます。

SAMLを採用すべき場面と見送るべき場面の条件付きの切り分け

SAMLを採用する判断は、既存環境で決まります。接続先がActive Directoryフェデレーションや主要IDaaSのSAMLコネクタで、社内アプリへの一括ログインを束ねたいなら、SAMLは実績のある選択です。多数のSaaSがSAML接続を標準提供している点も後押しになります。

逆に、これから作るのがモバイル主体のサービスで、接続先IdPもOIDCを話せるなら、SAMLは見送ってOIDCに寄せた方が実装は軽く済みます。XMLの署名処理はモバイル環境と相性が悪く、無理に載せると保守コストがかさみます。「既存IdPがSAML前提かどうか」を最初の分岐に置き、そうでなければOIDCを既定にするのが、遠回りしない設計方針です。自社の会員基盤や業務システムにSAML SSOを組み込む設計・実装は、会員管理システム開発として認証連携ごと受託しています。要件整理の段階からご相談ください。なお、SSO以前の本人確認の底上げには、二段階認証とは？二要素認証・多要素認証との違いと企業の導入判断を解説で導入判断の考え方を整理しています。

よくある質問

SAMLの導入検討でよく挙がる疑問を、実装者の視点で簡潔にまとめます。

SAMLとSSOは同じ意味ですか？

同じではありません。SSO（シングルサインオン）は1度のログインで複数サービスを使える「仕組みの概念」で、SAMLはそれを実現する「規格の1つ」です。SSOはSAMLのほかOIDCやKerberosでも実現でき、SAMLはWebのフェデレーション型SSOで広く使われる実装手段という関係になります。

SAMLとOAuthはどちらを使うべきですか？

目的で分かれます。ユーザーのログイン（認証）と属性連携が主目的ならSAMLかOIDC、外部サービスへのAPIアクセス権限を委譲したい（認可）ならOAuth 2.0です。OAuth 2.0単体を認証代わりにするのは本人性の保証が弱く、その用途にはOAuth 2.0の上に認証層を足したOIDCが向いています。

SAML 2.0と1.1の違いは何ですか？

SAML 2.0は2005年にOASISが承認した版で、それ以前のSAML 1.1やShibbolethの仕様を統合し、SP-Initiatedフローやメタデータ交換、SLOなどを整理したものです。現在の企業SSOやSaaS連携はほぼSAML 2.0を前提としており、新規実装で1.1を選ぶ場面は限られます。

SAML認証にはどんなセキュリティリスクがありますか？

最大の穴は署名検証の不備です。IdP署名を検証しない、アルゴリズムを緩める、有効期限やAudienceを見ないといった実装は、偽造・再送・使い回しを許します。XML Signature Wrapping攻撃も知られるため、検証は自作せず実績あるライブラリに任せ、最新版へ追随する運用が現実的な対策になります。

SAMLの導入に自社開発は必要ですか？

接続する両側の作り込み次第です。市販SaaSと主要IdPの組み合わせなら管理画面の設定だけで済むこともあります。一方、自社製アプリをSPにする場合は、メタデータ交換・署名検証・セッション連携の実装が必要で、ここは既存のSAMLライブラリを土台に組むか、認証連携に慣れた開発会社へ委託する判断になります。

関連記事

• OAuth 2.0とは？仕組み・認可フローと認証・認可の違いをわかりやすく解説：SAMLと対になる「認可」の規格。API権限委譲の仕組みを実装視点で解説しています。
• OIDC（OpenID Connect）とは？仕組み・OAuthとの違いをわかりやすく解説：OAuth 2.0の上に載る認証層。SAMLの代替として新規サービスで選ばれる場面を整理しています。
• 二段階認証とは？二要素認証・多要素認証との違いと企業の導入判断を解説：SSOの前段となる本人確認の強化策。導入判断の考え方をまとめています。