IT用語集 2023/11/08

SAML認証とは？シングルサインオンの仕組みやメリット・デメリットなどを解説

認証

SAMLは、IdPとSPの双方が対応している環境において、ブラウザを介した認証連携によってシングルサインオン（SSO）を実現するための代表的な仕組みの一つです。クラウドサービスの普及により、業務で使うSaaSや社内システムが増えた現在、SSOは「ログインの手間を減らす」だけでなく、認証のセキュリティレベルをそろえたり、権限管理をまとめたり、退職・異動時のアクセス制御を運用で揃えたりするうえでも役立ちます。

一方で、SAMLは「なんとなくSSOができる規格」という理解のまま導入すると、属性設計の不備や証明書更新の事故、サービスごとのログアウト挙動の違いなどが原因でトラブルになりがちです。この記事では、SAML認証の概要・仕組み・メリットと注意点を、運用やセキュリティの観点まで含めて整理します。あわせて、OAuthやOpenID Connectとの違い、利用例、導入時に押さえるべき設計ポイントも解説します。

SAML認証とは

SAML（Security Assertion Markup Language）は、異なるドメイン間でユーザーの認証結果や属性情報を連携するための標準規格です。XML形式の「SAMLアサーション」をやり取りし、「このユーザーはIdPで認証済みである」「このユーザーはどの属性（所属、メールアドレス、グループ等）を持つ」といった主張を、ログイン先のサービスへ伝えます。

企業利用では、社内の認証基盤を起点に複数のSaaSへSSOする用途で広く使われています。特徴は、多くのSAML連携ではSP（ログイン先サービス）がユーザーのパスワードを直接扱わず、IdP（認証を行う側）が発行した認証結果をSPが検証して受け入れる、という役割分担にあります。

シングルサインオンとは

SSOとは、一度のログインで複数のシステム・サービスへアクセスできるようにする仕組みです。SSOがない場合、SaaSや社内システムごとにログイン操作が必要になり、パスワード管理が分散して運用事故（使い回し、放置アカウント、退職者の残存）も起きやすくなります。SSOを導入すると、認証を一カ所に集約し、MFAや条件付きアクセスの適用もそろえやすくなります。

SSOについてより詳しく知りたい方は、こちらの記事も併せてご覧ください。

「シングルサインオンとは？仕組みやメリットを解説」

SAMLでよく登場する用語

IdP（Identity Provider）：ユーザー認証を行い、認証結果（アサーション）を発行する側
SP（Service Provider）：SSOでログイン先となるシステム・サービス（SaaSなど）
SAMLアサーション：認証結果やユーザー属性などをまとめたXMLデータ
メタデータ：IdP/SPのエンドポイントURLや証明書など、連携に必要な設定情報
ACS（Assertion Consumer Service）：SP側でSAML応答（レスポンス）を受け取る受信先
NameID：ユーザーを識別するための識別子（メールアドレス形式、永続IDなど方式がある）
属性（Attribute）：部署、役職、メール、グループなど、認証後にSPへ渡す追加情報
バインディング（Binding）：HTTP-Redirect、HTTP-POSTなど、SAMLメッセージを運ぶ方式

SAMLが得意な領域

SAMLは、企業内の認証を起点に外部SaaSへSSOする「企業向けのフェデレーション」に向いている仕組みです。特に、IdPとSPの双方が「企業利用の管理」を前提にしているSaaSでは、SAMLが標準的なSSO方式として採用されていることが多く、導入時の互換性や実績という点で有利です。

OAuthとSAMLの違い

OAuth（OAuth 2.0）とSAMLは、目的が異なります。整理すると、OAuthは「認可（Authorization）」の枠組み、SAMLは「認証（Authentication）の結果連携」に強い仕組みです。

認可：あるリソース（例：API、データ）へのアクセス権限を与えること
認証：そのユーザーが「誰なのか」を確認すること

たとえば、写真アプリがクラウドストレージ上の写真へアクセスする場合、ユーザーのパスワードをアプリに渡すのではなく、「このアプリに写真へのアクセス権限だけを委任する」ためにOAuthが使われます。一方で、企業のSSOのように「ログインしたユーザーが誰か」をSPへ伝え、業務アカウントとしてログインを成立させる用途ではSAMLが多用されます。

混同しやすいポイント

OAuthにもログイン体験があるため「OAuthでSSOができる」と言われることがありますが、OAuth 2.0は、設計上「認証」ではなく「認可」を目的とした枠組みであり、単体ではログイン用途の認証仕様としては定義されていません。ログイン用途として成立させるには、OAuth 2.0に認証要素を追加したOpenID Connect（OIDC）などを用いるのが一般的です。

OpenID ConnectとSAMLの違い

OpenID Connect（OIDC）とSAMLはいずれも認証連携に使われますが、設計思想と実装形態が異なります。OIDCはOAuth 2.0をベースに、IDトークン（多くはJWT）を用いて「ログインしたユーザーが誰か」を伝える仕組みです。一方、SAMLはXMLベースのアサーションをやり取りして認証を実現します。

実務上の選定で効く違い

方式選定で差が出やすいのは、次のような観点です。

対象サービスの対応状況：SaaSがSAMLのみ対応、またはOIDCのみ対応のケースがある
アプリの性質：モダンWebアプリやAPI主体の構成ではOIDCが導入しやすいことが多い
既存のIdP基盤：IdPがSAML連携を前提に整備されている場合、SAMLが展開しやすい

なお、企業環境では「SaaSはSAML、内製アプリはOIDC」というように併用するケースも珍しくありません。重要なのは、方式そのものよりも「IdPでの認証のセキュリティレベルをそろえ、権限とアカウントライフサイクルを運用でコントロールできるか」です。

SAML認証の仕組み

ここではSAML認証の構成要素と認証フローを、運用で問題になりやすい点も含めて整理します。

SAML認証の構成要素

SAML認証では、次の3者間で情報をやり取りします。

利用者（ユーザー）
SP（Service Provider）：ログイン先のシステム・サービス
IdP（Identity Provider）：認証情報の管理・認証処理を行うサービス

通常の認証では利用者とSPが直接やり取りします。SAMLではIdPが認証を担い、SPは「IdPが発行した認証結果（SAMLアサーション）を検証して受け入れる」ことでログインを成立させます。ユーザーはIdPで一度認証すれば、複数のSPへSSOできるようになります。

SP initiatedとIdP initiated

SAML認証のフローは、利用者がSPとIdPのどちらにアクセスするかによって代表的に2種類あります。

利用者がSPにアクセスする場合

利用者がSPにアクセス
SPが認証要求（AuthnRequest）を生成し、利用者をIdPへリダイレクト（またはPOST）
利用者がIdPで認証処理（ID/パスワード、MFAなど）を実施
認証が成功すると、IdPがSAML応答（SAMLResponse）を発行
利用者のブラウザ経由でSAML応答がSPのACSへ送信され、SPが検証してログイン完了

利用者がIdPにアクセスする場合

利用者がIdPにアクセス
利用者がIdPで認証処理（ID/パスワード、MFAなど）を実施
利用者が利用するSPを選択し、IdPがSAML応答（SAMLResponse）を発行
利用者のブラウザ経由でSAML応答がSPへ送信され、SPが検証してログイン完了

どちらを選ぶべきか

現場の運用では、SP initiatedが「ユーザーが普段のURLから入る」導線に合いやすく、IdP initiatedは「ポータルからアプリを起動する」導線に合いやすい傾向があります。ただし、サービスによってはIdP initiatedで要求と応答の紐付けが弱くなり、監査や不正検知の観点で扱いづらい場合があります。対象サービスの推奨方式と、ログや追跡性の要件も踏まえて選定します。

SAMLResponseに含まれる主な情報

SAMLResponseには、認証結果（成功/失敗）、ユーザー識別子（NameID）、属性情報（メールアドレス、所属など）、有効期限などが含まれます。SPはこれらを検証し、「想定するIdPから発行されたものか」「期限内か」「宛先が正しいか」などを確認して受け入れます。

検証で重要になりやすい項目

署名の検証：改ざんされていないか、信頼できる発行者か
Audience：このアサーションの受け手が自分（そのSP）であるか
Recipient：SAMLResponseの送信先（ACS）が想定通りか
NotBefore / NotOnOrAfter：有効期限内か（時刻ずれも考慮）
InResponseTo：要求（AuthnRequest）に対する応答として成立しているか

ここが曖昧な実装や設定になっていると、受け入れてはいけない応答を受け入れるリスクが増えます。サービス側の実装品質に左右される部分もあるため、導入前の検証で「何がチェックされているか」を把握しておくと安全です。

バインディングと実装上の勘所

SAMLメッセージの運び方として、HTTP-RedirectやHTTP-POSTなどのバインディングが使われます。一般的に、AuthnRequestはRedirect、SAMLResponseはPOSTで送られる構成が多いですが、サービスや設定により変わります。

運用で問題になりやすい点

RelayState：ログイン後の遷移先などを保持する値で、サービスによって制約がある
大きい属性の扱い：属性量が増えるとメッセージが大きくなり、制限に当たることがある
ブラウザ制約：サードパーティCookieの制限やポップアップ制御が影響する場合がある

SSOは「認証の規格」だけでなく、ブラウザ挙動やネットワーク制限も絡みます。特に社内端末の制御が強い環境では、事前に対象端末・対象ブラウザでの検証が重要です。

署名・証明書と安全性

SAML連携では、SAMLResponseやアサーションに対して電子署名（署名検証）を用いるのが一般的です。これにより改ざんやなりすましのリスクを抑えられます。必要に応じてSAMLアサーションやNameIDを暗号化する構成もありますが、暗号化だけで安全性が担保されるわけではなく、署名検証や実装・運用との整合が重要になります。

証明書更新が実運用の山場になりやすい理由

SAMLで使う署名証明書には有効期限があり、期限切れや更新漏れはSSO停止の原因になり得ます。さらに、証明書更新は「IdP側だけ替えれば終わり」ではなく、SP側が参照するメタデータ更新や、証明書ロールオーバー（旧証明書と新証明書の併用期間）の設計が必要になる場合があります。更新手順を平常時から整備し、検証環境で更新リハーサルをしておくと事故を減らせます。

SAML認証とSSO運用の考え方

SAML認証ではIdPが認証を担うため、SPがSAMLに対応していればSSOを実現しやすくなります。SPはユーザーのID/パスワードを保持せず、IdPが発行する認証結果（アサーション）を検証してログインを成立させます。

フェデレーション方式とは

SAMLは一般にフェデレーションの考え方でSSOを実現します。フェデレーション方式とは、異なるドメイン間で認証状態やユーザー属性を連携する方式です。ここでやり取りされるのはID/パスワードそのものではなく、認証結果と属性がまとまったSAMLアサーションです。

シングルログアウトの扱い

シングルログアウト（SLO）は、SPまたはIdPでログアウトした際に関連セッションも終了させる仕組みです。ただし、すべてのサービスがSLOに対応しているわけではなく、挙動の差も出やすいのが実態です。運用では「ログアウトに期待しすぎない」設計が重要で、端末共有や離席の多い環境では、セッションタイムアウトや端末ロック、条件付きアクセスと組み合わせて安全性を確保します。

アカウントライフサイクルは別で考える

SAMLは「ログインできるか」を連携する仕組みであり、ユーザーの作成・変更・削除を自動化する仕組みではありません。SSOだけ導入すると、退職者がSaaS側に残り続けるなどのリスクが残るため、必要に応じてプロビジョニング連携（例：SCIM）や、JIT作成（初回ログイン時に作る）といった運用も含めて検討すると、運用上の管理をしやすくなります。

SAML認証のメリット

SAML認証（SSO）には、主に次のようなメリットがあります。

ユーザー体験の向上

複数のサービスを個別にログインする手間が減り、日々の業務効率が上がります。特にSaaS利用が多い環境では、ログイン回数の削減が体感しやすい効果になります。

認証強度の統一によるセキュリティ向上

SAMLでは、原則としてSPにID/パスワードを渡しません。認証をIdPに集約することで、MFAや条件付きアクセス、端末制御などを一貫して適用しやすくなります。サービスごとに強度がバラつく状態を減らせる点は、実務上のメリットです。

属性・権限の一元管理

IdPでユーザー属性やグループを管理し、サービスごとにアクセス可否を制御しやすくなります。異動や組織変更の影響を属性・グループで吸収できるように設計すると、運用負荷と事故の両方を減らしやすくなります。

SAML認証のデメリットと注意点

一方で、導入・運用時には次のような注意点も理解しておく必要があります。

IdPが重要インフラになる

認証がIdPへ集約されるため、IdPが侵害されたり停止したりすると影響範囲が広がります。SAML導入では、IdPの保護と運用設計が前提になります。具体的には、管理者MFA、管理者権限の最小化、監査ログの保全、冗長化、障害時の迂回手段、緊急時のロール対応などを事前に用意します。

連携設定の調整項目が多い

SAML連携は、メタデータ、証明書、ACS、NameID、属性、署名要否など、調整項目が多くなりがちです。特に社内システム側でSAML対応が十分でない場合、属性マッピングやセッション管理の設計を追加で検討する必要があり、導入までの工数が増えることがあります。

証明書更新とメタデータ更新が必須

SAMLで用いる証明書の更新漏れはSSO停止に直結します。期限管理だけでなく、更新時の段取り（併用期間、影響範囲、検証、切り戻し）を運用として決めておくことが重要です。特にSaaS側の更新反映に時間や手作業が必要な場合、作業の属人化を避けるための手順化が欠かせません。

サービス実装差による落とし穴がある

SAMLは標準規格ですが、SPごとにサポート範囲や検証の厳しさが異なることがあります。たとえば「Responseは未署名でも受け入れる」「InResponseToを厳密に見ない」「属性の必須条件が独自」など、挙動差がトラブルの原因になります。導入時は、想定するセキュリティ要件（署名必須、Audience/Recipient検証、期限検証など）を満たすかをテストで確認します。

SAML認証の使用例

企業内での利用例

グループウェア、勤怠管理、経費精算、CRM、文書管理など、業務で利用するサービスが増えるほどSSOの価値は高まります。従来は社内ディレクトリ中心だった環境でも、クラウドサービスとの統合を見据えてSAML連携を取り入れ、認証基盤を整備する例が多く見られます。

SaaSへのSSOの典型構成

多くのSaaSがSAMLに対応しているため、社内のIdPで認証し、各SaaSへSSOする構成が一般的です。サービスごとにID/パスワードが散在すると、利用者の負担だけでなく、退職者の残存や権限の過剰付与といった管理上のリスクも増えます。SAMLで認証を統合し、属性設計とあわせてアクセス制御を整えることで、管理と利便性を両立しやすくなります。

SAML認証の導入で押さえるポイント

対象範囲と到達目標を明確にする

最初に「どのサービスをSSO対象にするか」「どの利用者層が対象か」「どこまで管理したいか」を明確にします。たとえば、まずは主要SaaSのSSOから始めるのか、全社ポータルを含めた導線まで作り込むのかで、必要な設計と運用が変わります。

認証強化を前提に設計する

SSOは便利になる一方で、IdPを突破されると影響が大きくなります。MFAはもちろん、端末条件、場所条件、リスクベース制御など、現実的に適用可能な条件付きアクセスを組み合わせ、IdPを堅牢知道します。特に管理者アカウントの保護は優先度が高く、一般ユーザーより強い制御が必要です。

属性設計と権限設計を先に決める

「どの属性をどのサービスに渡すか」「どの属性でアクセス制御するか」を先に設計します。ここが曖昧だと、サービスごとに個別運用が増え、異動・兼務・例外対応で破綻しやすくなります。まずは必要な属性に絞り、運用しながら段階的に追加する設計も有効です。

アカウント運用まで含めて管理する

SSOだけではアカウントの洗い出しや運用の課題が残ることがあります。退職・休職・委託切替などのライフサイクルに合わせて、SaaS側のアカウントを確実に無効化できる仕組み（プロビジョニング連携、洗い出し手順、例外時の手動フロー）を整備します。

証明書更新を定常運用に組み込む

証明書の有効期限と更新手順を、年次作業として予定に組み込みます。更新で必要になる作業（メタデータ更新、併用期間の設定、検証、周知、切り戻し）を手順書化し、担当者が変わっても回る状態を作ることが重要です。

選定では運用性と監査性を見る

SAML認証のソリューションはさまざまで、オープンソースから商用製品まで選択肢があります。選定では、機能の多さだけでなく、監査ログの取得、管理者保護、冗長化、サポート、障害時の切り分けのしやすさなど、運用で効く要素を確認します。

まとめ

SAML認証は、異なるドメイン間で認証結果と属性情報を連携するための標準規格であり、SSOを実現する代表的な方式の一つです。仕組みは一見複雑ですが、「利用者・SP・IdPの3者で連携する」「IdPが認証を担い、SPはアサーションを検証してログインを成立させる」という基本を押さえると理解しやすくなります。

導入では、利便性だけでなく、IdPの保護、属性設計、証明書更新、アカウントライフサイクルまで含めて設計することが重要です。対象サービスの対応方式や運用体制、求めるセキュリティ要件に合わせて、最適な形を検討していきましょう。