SAML とは？初心者でもわかりやすく理解するポイント

セキュリティ開発•2025/1/24

はじめに

SAMLという言葉を耳にしたことがある方は多いかもしれません。企業のシステムやウェブアプリケーションの認証周りでよく使われる仕組みの一つです。いざ導入しようとすると、抽象的な説明ばかりで戸惑う場面もあるのではないでしょうか？

そこでここでは、SAML とは何かを初心者でもわかるように説明します。また、実際の利用シーンや具体的な実装例にも触れてみます。

SAMLの基本的な考え方

SAMLは主に認証や認可を安全にやり取りするための仕組みとして活用されます。正式名称はSecurity Assertion Markup Languageですが、略称のSAMLのほうがよく使われています。複数のシステムをまたいでシングルサインオンを実現したいとき、SAMLは便利です。

SAMLはXMLベースでやり取りされる点が特徴です。情報の交換には認証情報やユーザの属性（メールアドレスやユーザIDなど）を含むことがあり、それをSAMLアサーションと呼びます。こうしたアサーションを安全にやり取りすることで、ユーザは一度ログインするだけで複数のサービスを利用しやすくなります。

SAMLが使われる場面の例

SAMLは大規模な企業システムなどでよく利用されます。社内システムが複数存在していて、それぞれにログインを繰り返すのは手間ですよね。そのため、ある一つの認証プロバイダ（Identity Provider）でログインが完了すると、ほかの業務システムにも自動でログインできるようにするケースでSAMLはとても有用です。

一方で、外部のクラウドサービスとの連携にも使われることがあります。たとえば、社内のID管理システムをIdentity Providerとして利用し、外部のサービスがService Providerとして連携する例があります。このように、SAMLは「組織内部」や「組織外部と組織内部の接続」など、多様な場所で活躍しているのです。

SAMLを理解するための用語

SAMLでは用語が多く登場します。なんとなく聞き慣れない単語が多いと感じるかもしれません。ここではよく使われる用語を簡単に押さえておきましょう。

Identity Provider (IdP)

ユーザを認証する役割を担うサービスです。ユーザのログイン情報を管理し、ログイン成功の結果を相手に伝えます。企業の社内認証サーバがIdPになるケースがよくあります。

Service Provider (SP)

サービスを提供する側です。ユーザを直接認証せず、IdPが出す認証情報（SAMLアサーション）をもとに、利用者が正しいユーザかどうかを判断します。ウェブアプリやクラウドサービスがこれに当たります。

SAMLアサーション

IdPが発行するデータのことです。 XML形式でユーザの認証結果や属性情報が含まれます。 SPはこのアサーションを受け取ってユーザを信用します。

SAMLリクエスト / SAMLレスポンス

SPがIdPへ送る認証要求をSAMLリクエスト、IdPが返す認証情報をSAMLレスポンスと呼びます。ブラウザのリダイレクトやHTTP POSTを通じて交換されるのが特徴です。通信はHTTPSで暗号化されるため、安全にやり取りできるようになっています。

仕組みの流れをざっくり把握する

SAMLの仕組みをもう少し実務的に見てみましょう。以下はユーザがブラウザを使い、SPとIdP間でSAMLをやり取りするケースの簡単な流れです。

ユーザがSPのウェブサービスにアクセスする
SPはユーザがログイン済みかチェックし、まだならIdPへのログインを求めるSAMLリクエストを生成
ユーザは自動的にIdPのログインページへリダイレクト
IdPはユーザ名やパスワードを確認し、認証に成功したらSAMLアサーションを含むSAMLレスポンスを生成
ブラウザがSAMLレスポンスを受け取って、SPへ再度リダイレクト
SPはSAMLアサーションを検証し、正しいユーザであればセッションを開始してサービスを利用可能にする

上記の流れを実装するとき、実際にはSAML向けのライブラリやツールを使うことがほとんどです。 XMLのデータや証明書の設定も絡むため、手作業で組むよりもフレームワークに任せるのが一般的です。

OAuth2やOpenID Connectとどう違うのか

SAMLと混同されやすいのがOAuth2やOpenID Connectです。たしかに「認証を外部に委ねる」という点で似ていますが、いくつか違いがあります。

まず、SAMLはXMLベースの仕様ですが、OAuth2やOpenID ConnectはJSONやRESTful APIを多用する傾向があります。また、SAMLは企業システムのシングルサインオンを強く意識しており、エンタープライズ寄りの印象が強いです。一方、OAuth2やOpenID Connectはウェブやモバイルアプリでも使いやすい形式になっています。

実務での使い分けとして、既にSAMLを前提とした社内システムや既存のIdPがあるならSAMLを使うことが多いです。逆に、ウェブサービスを個人ユーザが利用する際にはOAuth2やOpenID Connectが使われるケースが主流になりつつあります。どちらが優れているというわけではなく、目的や導入背景で使い分けるのが一般的でしょう。

実際の利用例と考え方

実務では「SAMLメタデータ」と呼ばれるXMLファイルを、IdPとSPで交換する作業が発生します。メタデータには公開鍵やエンドポイントURLなど、双方が連携するために必要な情報がまとまっています。これを互いに設定することで、認証要求や認証結果のやり取りが可能になります。

さらに、大規模な環境ではSAML認証の要件が複雑になることもあります。たとえば、ユーザの属性を詳細に定義し、どの役職の人がどのシステムを使えるかをSAMLアサーションに含めたりします。こうした情報をもとにアクセス制御を実現することで、柔軟なセキュリティ運用ができるようになります。

サンプルコードのイメージ（Node.js編）

ここではNode.jsでシンプルにSAML連携を導入する例を見てみます。実際には企業システムなどで多くの設定が必要になる場合がありますが、最小限のイメージを掴む上で参考にしてください。


// 必要なライブラリをインストールしておく
// npm install express passport passport-saml --save

const express = require("express");
const passport = require("passport");
const SamlStrategy = require("passport-saml").Strategy;

const app = express();

// パスポートの設定
passport.use(
  new SamlStrategy(
    {
      // IdPから提供されるメタデータやエンドポイントURL、証明書などを設定
      entryPoint: "https://example-idp.com/sso",
      issuer: "https://your-app.com",
      cert: `-----BEGIN CERTIFICATE-----
MIIDXXXXX...（省略）...XXXXX
-----END CERTIFICATE-----`,
      // ここにコールバックURLやサインイン後の処理を入れる
      callbackUrl: "https://your-app.com/login/callback",
    },
    (profile, done) => {
      // 認証後のユーザ情報(profile)を必要に応じて処理
      return done(null, profile);
    }
  )
);

app.use(passport.initialize());

// SAMLログイン開始
app.get("/login", passport.authenticate("saml", { failureRedirect: "/error" }));

// SAMLコールバックURL
app.post(
  "/login/callback",
  passport.authenticate("saml", { failureRedirect: "/error" }),
  (req, res) => {
    // 認証成功後の処理
    res.send("Login successful with SAML!");
  }
);

app.listen(3000, () => {
  console.log("Server is running on port 3000");
});

上記の例では、passport-samlというライブラリを使っています。 IdPのメタデータや証明書などを正しく設定すると、SAMLを利用してログインが可能になります。 SP（上のNode.jsサーバ側）とIdPの間で認証情報が正しくやり取りされると、ユーザは自分の組織アカウントなどでログインできるようになるでしょう。

SAML導入時に考慮すべきポイント

SAMLを実際に導入する際には、いくつかのポイントを押さえておくとスムーズです。認証基盤にまつわる設定はシステム全体のセキュリティに関わるので、慎重に進めることが大切になります。

証明書の管理

SAMLではXML署名や暗号化に証明書を使う場面があります。証明書の有効期限が切れると認証がうまく動かなくなるため、更新作業のスケジュールを管理する必要があります。また、紛失や漏洩がないように安全な場所に保管しましょう。

メタデータの整合性

SPとIdP両方でメタデータのURLや証明書情報を更新した場合、どちらかが古い情報のままだと連携に失敗することがあります。メタデータを更新した後は、しっかりとテストして動作を確認することが欠かせません。

属性情報の取り扱い

ユーザの役職や部署、メールアドレスなどをSAMLアサーションに含めることがあります。これらの情報をSP側でどう扱うか、システム全体の設計を考慮しながら決めることが大切です。不必要に多くの情報を含めないなど、最小限のデータで連携するのもセキュリティの観点では重要です。

SAML連携が失敗するとユーザがログインできなくなるリスクがあります。導入時はテスト環境で十分に検証してから本番リリースすることが望ましいです。

エンタープライズシーンでのリアルな活用イメージ

企業でのSAMLの使われ方をもう少し具体的に想像してみましょう。たとえば、大手企業の社内システムは10以上のウェブアプリに分かれていることが珍しくありません。部署やプロジェクトごとに異なるアプリを使う場合、従来はアプリごとにログインが必要でした。

SAMLを導入すると、ユーザは1回だけ社内の認証ページ（IdP）でログインすれば済みます。あとはどのアプリにアクセスしても、自動的にIdPからの認証情報が渡されてログインが完了します。 IDとパスワードを何度も入力する手間が減るうえ、パスワードの使い回しリスクも下がると考えられます。

また、ユーザの入退社に伴うアカウント管理も楽になります。新入社員のアカウントを1か所で作成し、SAML連携したシステムに自動的に反映させるといった運用が可能になるからです。このように大規模組織ほど、SAMLの利点は大きくなります。

メリットとデメリット

SAMLを導入するうえで、メリットだけでなくデメリットにも触れておきましょう。どちらも把握しておくとシステム選定に役立ちます。

メリット

シングルサインオンを実現しやすい
一括管理でユーザの操作を最小限にできる
企業規模での認証連携に強い

これらのおかげで、ユーザ体験やセキュリティ運用がまとまりやすくなるでしょう。

デメリット

XMLベースの実装や設定がやや複雑
OAuth2やOpenID Connectに比べるとモダンな開発環境では面倒に感じることがある
設定ミスや証明書のトラブルが起きると連携が一斉にダウンするリスクがある

特に証明書の期限切れはSAML運用の定番トラブルなので、こまめな管理が欠かせません。

実装時のトラブルシューティング

SAMLを設定したのに、なぜかユーザが認証されないことがあります。多くの場合、証明書かメタデータの設定ミスが原因になることが多いです。スペルや大文字小文字の違いでも不備が起こるので、設定ファイルを見直すと解決することがあります。

もしコンソールログやサーバのログにエラーが出ている場合は、その内容をしっかり確認しましょう。 SAMLのエラーは初見では分かりにくいメッセージが出ることがあるので、よく使うライブラリのドキュメントに掲載されているエラーコード一覧を参照するとヒントが得られます。

また、ネットワーク的に通信が遮断されているケースもあります。ファイアウォールやリバースプロキシが絡む大規模環境では、外部通信を許可しないとSAMLリクエスト・レスポンスのやり取りが失敗するかもしれません。こうしたインフラ周りの設定も含めて再確認するのが、トラブル回避の近道です。

SAMLの設定情報は一つでも齟齬があると連携に失敗します。疎通確認を分割して行い、どこで通信が失敗しているかを切り分けることが重要です。

セキュリティ面で気をつけたいこと

SAMLは安全性を保つための仕組みが豊富に取り入れられています。しかし、それを正しく運用しないと狙い通りのセキュリティを確保できない場合もあります。

HTTPSの導入

ブラウザとサーバ間の通信を暗号化し、SAMLのデータが傍受されないようにする

XML署名

IdPやSPが送るSAMLメッセージに署名をつけ、不正な改ざんを検出する

証明書管理の徹底

不正な証明書や期限切れの証明書を使わないように運用ルールを決める

これらを踏まえて一通り設定したら、社内の監査部門やセキュリティ担当とも協力しながら定期的に点検していくのがおすすめです。

大規模環境とSAMLの相性

SAMLは大規模な組織や多数のシステムが存在する環境でこそ活躍します。一度設定してしまえば、各システムがIdPとつながるだけで一気通貫の認証連携が可能になるからです。ただし、その分初期の導入ハードルはやや高いと感じるかもしれません。

大規模環境ほど、ユーザが増えたときや新しいシステムを追加したときのメリットが大きくなります。もともと複数システムでバラバラの認証が行われていたものを統合できるのは、管理者にとっても楽になる要素が多いでしょう。そうした組織全体の負担軽減を見込めるのがSAMLの強みです。

SAMLと他の認証技術のハイブリッド運用

最近は、企業によってはSAMLだけではなくOAuth2やOpenID Connectも併用するケースが出てきています。社内で使うアプリケーションはSAML、外部向けのマイクロサービスはOAuth2やOpenID Connect、というように分けることで柔軟性を確保しているのです。どの技術を採用するかは、アプリケーションの性質やユーザ数、運用方針などを総合的に判断します。

SAMLはエンタープライズ寄り、OAuth2やOpenID Connectはウェブやモバイル寄りの利用に強いイメージがあり、相互補完的に使われることも少なくありません。このように複数の認証技術を組み合わせることで、より多様な環境に対応できるようになります。

まとめ

SAMLは複数のシステム間での認証情報を安全にやり取りし、シングルサインオンを実現するための仕組みです。 XMLベースで認証結果などをやり取りするため、企業規模での導入が多いのが特徴です。

導入のハードルは少し高めかもしれませんが、大規模なシステムや組織であればあるほど、SAMLによる一元的な管理とシングルサインオンのメリットは大きくなります。また、OAuth2やOpenID Connectと合わせて使い分けることで、より広い認証要件に対応できるでしょう。

もし複数サービスを連携する仕組みを構築しようと考えているなら、SAMLは強力な選択肢の一つになるのではないでしょうか。この記事が、SAMLの基礎を理解するきっかけになれば幸いです。