こんにちは、InfraAcademyを運営しているryuです。
今回は、SAML認証の仕組みをIT初心者向けに解説します。
会社でクラウドサービスを使っていると、サービスごとにパスワードを入力せず、会社のアカウントでそのままログインできることがあります。このようなシングルサインオンを実現するときによく使われる仕組みの一つがSAMLです。
SAMLを調べると、IdP、SP、Assertion、AuthnRequestなど見慣れない言葉が一気に出てきます。しかし、最初に登場人物を整理すると、それほど難しい仕組みではありません。
この記事では、SAMLとは何か、IdPとSPは何をしているのか、ログイン時にどのような情報がやり取りされているのかを、順番に解説します。
SAMLとは?¶
SAMLは、Security Assertion Markup Languageの略です。
IdPとSPの間で、ユーザーの認証結果や属性などの情報をやり取りするためのXMLベースの標準です。企業向けのWebサービスでシングルサインオンを実現するときによく利用されています。
SAMLを使うと、利用するWebサービスごとにユーザー名とパスワードを管理するのではなく、会社が用意したIdPで認証をまとめやすくなります。
例えば、会社のアカウントで一度認証したあと、経費精算サービスや勤怠管理サービスへアクセスしたときに、再び個別のパスワードを入力せず利用できる構成を作れます。
SAMLとSSOは同じもの?¶
SAMLとSSOは同じ意味ではありません。
SSOはSingle Sign-Onの略で、一度の認証によって複数のサービスを利用しやすくする仕組みや利用体験を指します。SAMLは、そのSSOを実現するために利用できるプロトコルの一つです。
現在はSAML以外にもOpenID ConnectなどがSSOで利用されています。そのため、SAMLはSSOそのものではなく、企業のWebアプリケーションなどで広く利用されているSSO方式の一つと考えると分かりやすいです。
SAMLで覚えたい3つの登場人物¶
SAMLの流れを理解するために、まず3つの登場人物を整理します。
| 用語 | 役割 |
|---|---|
| User | サービスを利用する人 |
| IdP | ユーザーを認証する側 |
| SP | ユーザーへサービスを提供する側 |
IdPはIdentity Providerの略です。ユーザーが誰なのかを確認し、その認証結果をSPへ伝える役割があります。
SPはService Providerの略です。勤怠管理、グループウェア、経費精算など、ユーザーが実際に利用したいサービス側です。
Microsoft Entra ID、Okta、Google WorkspaceなどをIdPとして利用し、SAMLに対応したSaaSをSPとして連携する構成があります。
SAML認証の全体像¶
SAML認証の代表的な流れを先に見てみましょう。
- ユーザーがSPへアクセス
- SPがIdPへ認証を依頼
- IdPでユーザーを認証
- IdPがSAML Responseを作成
- ブラウザ経由でSPへ送信
- SPが内容を検証
- サービスを利用できる
重要なのは、ユーザーのパスワードをSPへそのまま渡しているわけではないことです。
ユーザー認証はIdP側で行い、SPはIdPが発行したSAMLの認証結果を検証してログインを許可します。
1. ユーザーがSPへアクセスする¶
まず、ユーザーが利用したいWebサービスへアクセスします。
例えば、会社で利用している勤怠管理サービスをSPと考えてみましょう。

画像は元記事作成時のログイン画面なので現在のUIとは異なる場合がありますが、考え方は同じです。
まだSP側にログインしていない場合、SPはユーザーをIdPへ誘導します。

2. SPからIdPへAuthnRequestを送る¶
SAMLのSP Initiated SSOでは、SPがIdPへ認証を依頼します。
このとき使われるのが AuthnRequest です。名前のとおり、ユーザーの認証を要求するためのメッセージです。
ユーザーのブラウザは、SPからのリダイレクトによってIdPのログイン画面へ移動します。
この流れでは、ブラウザがSPとIdPの間を移動しながらSAMLメッセージを運ぶ点も覚えておくと理解しやすくなります。
3. IdPがユーザーを認証する¶
IdPへ移動すると、まだIdPへログインしていない場合は認証を求められます。
認証方法は環境によって異なります。ユーザー名とパスワードだけでなく、多要素認証やパスキーなどを組み合わせる構成もあります。
ここで大切なのは、ユーザーの認証を行うのがSPではなくIdPであることです。
すでにIdPへログイン済みでセッションが有効なら、認証画面を再度表示せず、そのまま次へ進める場合があります。これがSSOを便利に感じる理由の一つです。
4. IdPがSAML Responseを作成する¶
認証に成功すると、IdPはSAML Responseを作成します。
SAML Responseの中には、SAML Assertionと呼ばれる情報が含まれます。
Assertionには、ユーザーを識別する情報や認証が行われたこと、必要に応じて所属やメールアドレスなどの属性が含まれることがあります。
SAMLはXMLベースなので、概念的には次のような情報をやり取りしています。
このユーザーはIdPで認証済みです
ユーザーIDは user@example.com です
所属情報は ○○部です
実際のSAMLメッセージはXML形式で、署名や有効期限など、SPが安全に検証するための情報も含まれます。
5. ブラウザ経由でSPへSAML Responseを渡す¶
IdPが作成したSAML Responseは、一般的なWebブラウザSSOではユーザーのブラウザを経由してSPへ送られます。

このとき、SP側にはAssertion Consumer Service、略してACSと呼ばれるSAML Responseの受け取り先があります。
ユーザーがSAMLのXMLを手作業でコピーするわけではありません。ブラウザによるリダイレクトやPOSTによって自動的に処理されます。
6. SPがSAML Responseを検証する¶
SAML Responseを受け取ったSPは、そのまま信用するわけではありません。
例えば、次のような内容を確認します。
- 信頼しているIdPが発行したものか
- デジタル署名が正しいか
- 自分のサービス向けに発行されたAssertionか
- 有効期限を過ぎていないか
- 送信先が正しいか
検証に成功すると、SPはそのユーザーをログイン済みとして扱い、サービスを利用できるようにします。
SAML認証でデジタル署名や証明書の設定が重要なのは、攻撃者が偽の認証結果を作ってログインすることを防ぐためです。
パスワードはSPへ渡るの?¶
SAMLを理解するときに重要なのが、ユーザーのパスワードの扱いです。
一般的なSAML SSOでは、ユーザーはIdPに対して認証します。SPへユーザーのパスワードそのものを渡して、SPがIdPの代わりにログインする仕組みではありません。
SPが受け取るのは、IdPによって発行・署名されたSAML ResponseやAssertionです。
そのため、複数のSaaSへ同じ会社アカウントでSSOする構成でも、各SaaSへ会社のパスワードを保存させる必要がありません。
Microsoft Entra IDをIdPとして使う場合¶
元記事ではAzure Active Directoryという名称を使っていましたが、現在はMicrosoft Entra IDという名称になっています。
Microsoft Entra IDは、企業向けSAMLアプリケーションのIdPとして利用できます。
Microsoft Entra IDでユーザーを認証し、SAMLに対応したSaaS側へ認証結果を渡します。
SAMLの仕組みを理解すると、Microsoft Entra IDのエンタープライズアプリケーションで設定するIdentifier、Reply URL、証明書などが何のためにあるのかも理解しやすくなります。
SP InitiatedとIdP Initiatedの違い¶
SAMLのSSOには、どこからログインを始めるかによって複数の流れがあります。
この記事でここまで説明したのは、ユーザーがSPへ最初にアクセスするSP Initiated SSOです。
一方、IdP側のポータルなどからサービスを選択してログインするIdP Initiated SSOもあります。
初心者の段階では、まずSP Initiatedの流れを理解しておけば十分です。実際のサービスによって、どちらの方式に対応しているかは異なります。
SAMLとOpenID Connectの違い¶
現在の認証を勉強すると、SAMLと一緒にOpenID Connectという名前もよく出てきます。
大まかに整理すると、SAMLはXMLを使う成熟した標準で、企業向けのWebアプリケーションや既存SaaSとのSSOで広く使われています。
OpenID ConnectはOAuth 2.0をベースにした比較的新しい認証プロトコルで、Webアプリケーションだけでなく、モバイルアプリなどでも利用しやすい仕組みです。
| SAML | OpenID Connect | |
|---|---|---|
| 主な形式 | XML | JSON / JWTが中心 |
| 主な用途 | 企業WebアプリのSSO | Web・モバイル・新しいアプリ |
| 長く使われている企業システム | 多い | 増えている |
| 現在も利用されているか | はい | はい |
SAMLが古いから使ってはいけない、ということではありません。既存の企業向けSaaSでは現在も広く利用されています。
SAMLでよく起きる設定ミス¶
SAMLは複数のシステムが連携するため、設定値が少し違うだけでもログインできなくなります。
特に確認したいのは、Entity ID、ACS URL、IdPの証明書、ユーザー属性のマッピングです。
例えばSP側が期待しているメールアドレス属性と、IdPが送信している属性名が違えば、SAML認証そのものには成功してもアプリ側でユーザーを特定できないことがあります。
また、証明書を更新したあとにSP側へ新しい情報が反映されていないと、署名検証に失敗する場合があります。
SAMLのトラブルでは、ログインできないという結果だけを見るのではなく、どの段階で止まっているのかを確認することが重要です。
SAMLを理解するなら認証の流れを図で追う¶
SAMLは用語だけ暗記すると分かりづらい技術です。
IdP、SP、Assertionをそれぞれ覚えるよりも、ブラウザがどこへ移動し、誰がユーザーを認証し、誰が認証結果を検証するのかを図で追う方が理解しやすくなります。
InfraAcademyでは、Linux、ネットワーク、サーバー、セキュリティなど、インフラエンジニアに必要な基礎を段階的に学習できます。
認証も単独の用語として覚えるのではなく、HTTPS、DNS、サーバー、アクセス制御などとつなげて理解すると、実務でも使いやすい知識になります。
SAML認証の仕組みまとめ¶
今回は、SAML認証の仕組みを初心者向けに解説しました。
SAMLで最初に覚えたいのは、IdPがユーザーを認証し、SPがその認証結果を受け取ってサービスを提供するという役割分担です。
代表的なSP Initiated SSOでは、ユーザーがSPへアクセスするとIdPへ移動し、IdPで認証します。認証後はSAML Responseがブラウザ経由でSPへ渡され、SPが署名や有効期限などを検証してログインを許可します。
SAMLを理解するときは、用語を一つずつ覚えるより、次の流れを頭に置いておくと分かりやすいです。
SPへアクセス
↓
IdPで認証
↓
SAML Responseを発行
↓
SPが検証
↓
ログイン完了
現在はOpenID Connectなど別の認証方式もありますが、SAMLは企業向けSSOで今も利用されている重要な仕組みです。




