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

SAML認証は、シングルサインオン（SSO）を実現する仕組みの一つです。クラウドサービスの普及などにより、業務で多くのサービス・システムを利用するようになった昨今、SSOは業務効率化や利便性向上のために欠かせない技術となりました。では、SSOで多く利用されるSAML認証とは、具体的にどのようなものなのでしょうか。

この記事では、SAML認証の概要や仕組み、メリット・デメリットについて解説するとともに、同じくSSOでよく使われるOAuthやOpenID Connectとの違い、利用例や導入の際のポイントを解説します。

SAML認証とは

SAML（Security Assertion Markup Language）とは、インターネットドメイン間でユーザー認証（および属性・権限情報の連携）を行うための標準規格です。XMLをベースにした「SAMLアサーション（主張）」と呼ばれる情報をやり取りし、ユーザーが本人であることや、所属・属性などを相手システムへ伝えます。

異なるドメイン間でもユーザー情報や属性（例：部署、役職、メールアドレス）などを連携できるため、クラウドサービス（SaaS）を中心にSSOの仕組みとして広く利用されています。

シングルサインオン（SSO）とは

SSOとは、一度のログインで複数のシステム・サービスへアクセスできるようにする仕組みです。SSOがない場合、社内システムや複数のクラウドサービスに都度ログインする必要があります。一方、SSOを導入していれば、一度のログインで自社システムや複数のクラウドサービスへ自動的にログインして利用できるようになります。

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

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

SAMLでよく登場する用語

• IdP（Identity Provider）：ユーザー認証を行い、認証結果（アサーション）を発行する側
• SP（Service Provider）：SSOでログイン先となるシステム・サービス（SaaSなど）
• SAMLアサーション：認証結果やユーザー属性などをまとめたXMLデータ
• メタデータ：IdP/SPのエンドポイントURLや証明書など、連携に必要な設定情報
• ACS（Assertion Consumer Service）：SP側でSAML応答（レスポンス）を受け取る受信先

OAuthとSAMLの違い

OAuth（OAuth 2.0）とSAMLの違いを簡単に整理すると、OAuthは「認可（Authorization）」の枠組み、SAMLは「認証（Authentication）」の連携に強い仕組みという位置づけになります。

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

たとえば「運転の権限（免許）を与える」のが認可であり、「免許証が本人のものか確認する」のが認証です。これをデジタルの世界で実現する際、OAuthは主に「第三者アプリに権限を委任してアクセスさせる」用途で使われ、SAMLは主に「企業内外のサービス間で認証状態を連携してSSOを実現する」用途で使われます。

OpenID ConnectとSAMLの違い

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

一般的に、SAMLは企業向けSaaSのSSOで根強く普及し、OIDCはモダンなWebアプリやAPI連携と相性が良い傾向があります。実際の選定では「対象サービスがSAML対応か、OIDC対応か」が大きな判断材料になります。

SAML認証の仕組み

ここではSAML認証の仕組みとして、構成要素と認証フローを簡単に解説します。

SAML認証の構成要素

SAML認証では次の3者間で情報をやり取りすることで認証を実現します。

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

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

SAML認証のプロセスとフロー

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

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

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

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

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

SAML応答（SAMLResponse）に含まれる主な情報

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

署名・証明書と安全性

SAML連携では、SAMLResponseやアサーションに対して電子署名（署名検証）を用いるのが一般的です。これにより、改ざんやなりすましのリスクを抑えられます。また、必要に応じてアサーション自体を暗号化する構成もあります。運用では、証明書の期限管理・更新手順（IdP/SP双方のメタデータ更新）が重要になります。

SAML認証とシングルサインオン（SSO）

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

そのため、IdP側でユーザー認証やMFA、サービスごとのアクセス制御（属性・グループによる割り当て）などをまとめて管理しやすくなり、複数サービスに対するSSOが現実的になります。

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

SSOの方式にはいくつか種類がありますが、SAMLは一般にフェデレーション（Federation）の考え方でSSOを実現します。フェデレーション方式とは、異なるドメイン間で認証状態やユーザー属性を連携する方式です。

ここでやり取りされるのは、ID/パスワードそのものではなく、認証結果や属性がまとまったSAMLアサーションです。SP側がSAMLに対応している必要はありますが、業務利用されるクラウドサービスの多くがSAML連携に対応しています。

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

シングルログアウト（SLO）とは、SPまたはIdPのどちらかでログアウト処理を行った際に、関連するセッションを終了させる仕組みです。SSOでは複数のサービスへログインできる反面、「ログアウトがサービスごとに残る」ケースも起きやすいため、SLOが有効な場面もあります。

ただし、実際にはすべてのサービスがSLOに対応しているとは限らず、挙動もサービスごとに差が出やすい点には注意が必要です。ログアウト運用（端末共有、セッションタイムアウト、ブラウザ終了時の挙動など）も含めて設計すると安全です。

SAML認証のメリット

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

ユーザー体験の向上

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

セキュリティの強化

SAMLでは、原則としてSPにID/パスワードを渡しません。SP側に認証情報が散らばりにくくなるため、管理の観点で有利です。また、IdP側に認証を集約することで、MFAや条件付きアクセス（端末状態、場所、リスクなど）を統一的に適用しやすくなります。

アクセス権限（属性）の一元管理

IdPでユーザー属性やグループ情報を管理し、サービスごとにアクセス可否を制御しやすくなります。人事異動や退職などの変更も、IdPを起点に整理しやすくなり、運用負荷の軽減にもつながります。

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

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

認証基盤（IdP）が“要”になる

認証がIdPへ集約されるため、IdPが侵害されたり、停止・障害が起きたりすると影響範囲が広がります。SAML導入では、IdPの強固な保護（MFA、管理者権限の最小化、監査ログ、冗長化など）が前提になります。

設定・連携の運用が複雑になりやすい

SAML連携は「メタデータ」「証明書」「属性（NameIDやattribute）」など、調整項目が多くなりがちです。特に社内システム側でSAML対応が十分でない場合は、追加実装や設計検討が必要になり、導入までの工数が増えることがあります。

証明書更新・メタデータ更新の運用が必須

SAMLで用いる証明書には有効期限があります。期限切れや更新漏れはSSO停止の原因になり得るため、更新計画・手順・検証環境の整備が重要です。

SAML認証の実際の使用例

企業でのSAML認証の使用例

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

クラウドサービス（SaaS）でのSAML認証の使用例

多くのSaaSがSAMLに対応しているため、社内の認証基盤（IdP）でログインし、各SaaSへSSOする構成が一般的です。クラウド利用が増えるほど「ID/パスワードがサービスごとに散在する」状態になりやすいため、SAMLで認証を統合するメリットが出やすくなります。

SAML認証の導入を考える際のポイント

導入のメリットとコストを評価する

SAMLには多くのメリットがある一方、IdPが重要インフラになることや、設定・運用の複雑さへの対策が必要です。導入判断では、ライセンス・構築費だけでなく、運用設計（監査、冗長化、障害対応、証明書更新）やトレーニングコストも含めて評価します。

認証強化（MFA）と条件付きアクセスを前提に設計する

パスワード単体の認証では、漏えいやフィッシングのリスクを避けにくくなります。SAML導入の効果を高めるためにも、MFAや端末条件・場所条件の制御などを組み合わせ、認証基盤としての強度を確保することが重要です。

属性設計とアカウント運用（退職・異動）を整備する

SAML連携では、どの属性をどのサービスへ渡すかが運用の要になります。また、SSOとあわせて、ユーザーの作成・変更・削除を各サービスへ反映する仕組み（プロビジョニング連携等）も検討すると、アカウント放置リスクを減らしやすくなります。

適切なSAMLソリューションを選択する

SAML認証を実現するソリューションはさまざまで、オープンソースから商用製品まで選択肢があります。セキュリティ要件（監査ログ、管理者保護、冗長化、サポート体制など）を明確にし、自社のニーズを満たす製品・構成を選定しましょう。

まとめ

SAML認証は、インターネットドメイン間でユーザー認証（および属性連携）を行うための標準規格であり、SSOを実現する代表的な方式の一つです。SAMLの仕組みは複雑に見えますが、「利用者・SP・IdPの3者で連携すること」「IdPが認証を担い、SPはアサーションを検証してログインを成立させること」を押さえると理解しやすくなります。

導入の際にはメリット・デメリットを理解した上で、自社の対象サービス、運用体制、セキュリティ要件に合う形で設計・選定を進めてみてはいかがでしょうか。

FAQ：SAML認証の基礎と導入

SAML認証とは何ですか？

SAMLは、異なるドメイン間で認証結果やユーザー属性を連携するための標準規格です。XMLベースのSAMLアサーションをやり取りし、SSO（シングルサインオン）の実現に広く利用されています。

SAMLのIdPとSPは何が違いますか？

IdPはユーザー認証を行い認証結果（アサーション）を発行する側、SPはそのアサーションを受け取り検証してログインを成立させるログイン先サービス側です。

SAMLは「認証」でOAuthは「認可」と言われるのはなぜですか？

OAuth 2.0は主に「第三者にアクセス権限を委任する」ための枠組み（認可）で、SAMLは主に「ログインしたユーザーが誰か」を連携しSSOを実現する用途（認証）で使われるためです。

OpenID Connect（OIDC）とSAMLはどう使い分けますか？

どちらも認証連携に使われますが、SAMLは企業向けSaaSのSSOで広く使われ、OIDCはモダンなWebアプリやAPI連携と相性が良い傾向があります。実際は「対象サービスが対応している方式」に合わせて選定することが多いです。

SAML認証はどのようにSSOを実現しますか？

ユーザーがIdPで認証し、IdPが発行したSAMLアサーション（SAMLResponse）をSPが検証することでログインを成立させます。これにより、ユーザーは一度の認証で複数のSPへログインしやすくなります。

SAMLの「SP initiated」と「IdP initiated」は何が違いますか？

SP initiatedはユーザーがSPにアクセスしてからIdPへ誘導される方式、IdP initiatedはユーザーがIdPにログインしてから利用するSPを選ぶ方式です。運用やログアウト挙動など、サービス側の要件に合わせて選択します。

SAML認証のメリットは何ですか？

ログイン回数の削減による利便性向上に加え、認証をIdPに集約してMFAや条件付きアクセスを適用しやすくなる点が大きなメリットです。属性・権限管理の一元化にもつながります。

SAML認証のデメリットや注意点は何ですか？

IdPが重要インフラになるため、侵害や障害時の影響範囲が広がりやすい点が注意点です。また、証明書・メタデータ・属性設計など連携設定の運用が複雑になりやすい傾向があります。

SAML連携では証明書更新が必要ですか？

必要です。SAMLでは署名検証などに証明書を使うことが多く、有効期限切れや更新漏れはSSO停止の原因になります。更新計画と検証手順を事前に整備しておくことが重要です。

SAML導入時に特に重視すべきポイントは何ですか？

MFAや条件付きアクセスなどの認証強化、IdPの冗長化と監査ログ、属性設計と権限設計、証明書・メタデータ更新手順、退職・異動時のアカウント運用まで含めて設計することが重要です。