社内で使うSaaSや自社で開発したWebアプリに、会社のID基盤で一度ログインすれば各サービスに入れる仕組み（シングルサインオン）を入れたい。そう考えたとき必ず出てくるのが「SAML 2.0のIdP（アイデンティティプロバイダー）」という言葉です。
Amazon CognitoやMicrosoft Entra ID、Oktaといった基盤の設定画面には「SAML 2.0 ID プロバイダーを追加する」といった項目や、メタデータ・署名証明書・属性マッピングの欄が並び、どちらがIdPでどちらがSPなのか、どの値をどこに入れればつながるのかで手が止まりがちです。
本記事では、SAML 2.0におけるIdPとSP（サービスプロバイダー）の役割分担から、認証の流れ、メタデータ・証明書・属性といった設定の要点、認証が通らないときの定番の原因まで整理します。あわせて、自社でSAML 2.0のIdPとして使えるID基盤（IDaaS）の選び方も解説します。設定を進めるための判断材料としてご活用ください。
自社にIdPが無い場合に使えるID基盤の選択肢は、記事後半の「選び方」で具体的に紹介します。
一括ダウンロードする
目次
一括ダウンロードする
SAML 2.0のIdPとは？SPとの役割分担
SAML 2.0のIdP（アイデンティティプロバイダー）とは、ユーザーを認証し、その結果を署名付きの「アサーション」としてサービス側に渡す役割を担う側です。これに対してSP（サービスプロバイダー）は、ユーザーがログインしたいサービスやアプリケーションで、認証そのものはIdPに任せ、IdPから受け取ったアサーションを検証してアクセスの可否を決めます。
「認証する側＝IdP」「サービスを提供し、認証を委ねる側＝SP」と押さえると、設定画面のどちらを自社が担うのかが整理しやすくなります。
IdPとSPは何を分担するのか
標準仕様の定義では、IdP（Identity Provider）は利用者の認証情報を作成・管理し、連携関係にある他のサービスに対して利用者の認証を提供するものとされています。SP（Service Provider）は利用者などにサービスを提供する側で、受け取ったアサーションをもとに本人を識別します。
アサーションは、認証が行われたこと・利用者の属性・アクセスの可否といった情報を含む、SAMLが発行するデータです。IdPが「この人は確かに本人です」という証明書のようなデータ（アサーション）を署名付きで発行し、SPがそれを受け取って信頼するかどうかを決める、という分担になります。
そもそもSAML 2.0とは
SAML（Security Assertion Markup Language）2.0は、異なるシステムの間で認証や属性の情報をやり取りするための、XMLをベースにした標準規格です。OASISという標準化団体が2005年に承認したオープン標準で、1つのID基盤でログインすれば複数のサービスに入れるシングルサインオンを実現する土台として、エンタープライズ向けのSaaS連携で広く使われています。
IdP・SP・アサーションという3つの登場人物の関係を定めているのがSAML 2.0であり、各クラウドの設定画面で求められる項目も、この規格が定める情報に対応しています。
SAML認証はどう流れるのか（SP-Initiated / IdP-Initiated）
SAML認証には、エンドユーザー・IdP・SPの3者が登場します。認証のきっかけがどちら側から始まるかで、SP起点（SP-Initiated）とIdP起点（IdP-Initiated）の2つのフローに分かれます。どちらを使うことになるのかは連携するサービスや構成で決まるため、まず両方の流れを押さえておくと、設定画面の「サインオンURL」や「応答URL」が何を指すのかが理解しやすくなります。
2つのフローで、誰が誰にどのメッセージを送るのかを図にすると、次のように整理できます。
SP-Initiatedフロー（サービス側から始まる）
SP起点のフローは、ユーザーが先にサービス（SP）へアクセスするところから始まります。SPはユーザーをIdPへリダイレクトし、ユーザーはIdPに対して認証します。認証が済むとIdPはSAML応答（アサーションを含む）をSPに送り、SPがその応答を検証してアクセスを許可します。
仕様上、この流れではSPからIdPへ認証を求める「<AuthnRequest>」というメッセージが送られ、IdPからSPへは「<Response>」が返されます。普段利用するSaaSで多いのがこのパターンです。
IdP-Initiatedフロー（ID基盤側から始まる）
IdP起点のフローは、ユーザーが先にIdP（社内ポータルなど）へアクセスし、IdPが認証してアサーションを発行するところから始まります。IdPはSAML応答とともにユーザーをSPへ送り、SPがその応答を検証してアクセスを許可します。
SP起点と違い、このパターンではSPからIdPへの「<AuthnRequest>」は発生せず、IdPからSPへ「<Response>」だけが流れます。社内ポータルのリンクから各サービスへ入らせたいときに使われる流れです。
出典・参考資料（2件）
SAMLアサーションの中身（NameID・属性・署名）
アサーションは、IdPがユーザーを認証した結果を詰めたXMLのデータです。中心となるのが、ユーザーを一意に識別する「NameID」、メールアドレスや所属などの属性（クレーム）、そしてデータの改ざんを防ぐ署名の3つです。SPはこの署名を検証したうえで、NameIDや属性の値からどのユーザーかを特定します。
設定でつまずきやすいのは、IdPが送るNameIDや属性の値と、SP側が期待する識別子がかみ合わないケースで、ここは後述のトラブルシュートでも取り上げます。
実際にやり取りされるXMLの骨格を見ると、どの値がどこに入るのかがつかみやすくなります。SPがIdPに認証を求める<AuthnRequest>と、IdPが認証結果を返すアサーションは、おおまかに次のような構造です（要点が分かるよう簡略化した代表例）。
<!-- SPからIdPへ：認証リクエスト -->
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
Destination="https://idp.example.com/sso"
AssertionConsumerServiceURL="https://sp.example.com/acs"> <!-- 送信先＝ACSエンドポイント -->
<saml:Issuer>https://sp.example.com</saml:Issuer> <!-- SPのエンティティID -->
<samlp:NameIDPolicy Format="...:nameid-format:emailAddress"/> <!-- 期待するNameID形式（応答のNameIDと揃える） -->
</samlp:AuthnRequest>
<!-- IdPからSPへ：アサーション（署名付きレスポンス内） -->
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<saml:Issuer>https://idp.example.com</saml:Issuer> <!-- IdPのエンティティID -->
<ds:Signature>...</ds:Signature> <!-- X.509で署名 -->
<saml:Subject>
<saml:NameID Format="...:nameid-format:emailAddress">user@example.com</saml:NameID>
</saml:Subject>
<saml:Conditions NotBefore="2026-01-01T00:00:00Z"
NotOnOrAfter="2026-01-01T00:05:00Z"> <!-- 有効期間（時刻ずれに注意） -->
<saml:AudienceRestriction>
<saml:Audience>https://sp.example.com</saml:Audience> <!-- 受け手＝SP -->
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AttributeStatement>
<saml:Attribute Name="email">
<saml:AttributeValue>user@example.com</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>設定画面で入力する「エンティティID」「ACSエンドポイント」「NameID形式」「属性」が、このXMLのどこに対応するかが分かります。とくに<Conditions>のNotBefore・NotOnOrAfterはアサーションの有効期間を表します。IdPとSPの時刻がずれるとこの期間を外れて認証に失敗するため、後述のトラブルシュートでも鍵になります。
出典・参考資料（1件）
IdPとSPをつなぐ設定の要点（設定項目×入力値の対応表）
ここからは、IdPとSPを実際につなぐときの設定項目を整理します。自社のID基盤をIdPとして使う場合は、つなぎたいSaaSやアプリ（SP）とペアで設定を進めます。自社開発のアプリにSSOを入れるときは、自社がIdPとSPの両方を設定します。
設定はおおまかに、メタデータの交換で信頼関係を作り、エンティティIDとACSエンドポイントを指定し、署名証明書を登録し、NameIDと属性をマッピングし、最後にテストで動作を確認する、という流れで進みます。
「メタデータ」「エンティティID」「ACSエンドポイント」「署名証明書」「NameID・属性マッピング」はどの基盤でも共通して登場します。各項目をIdP側とSP側のどちらで設定するのかを押さえると、設定画面で迷いにくくなります。
メタデータの交換で信頼関係を作る
IdPとSPは、まず互いの構成情報を交換して信頼関係を作ります。この構成情報をまとめたXMLがメタデータで、エンティティID・各種エンドポイント・署名証明書などが含まれます。渡し方は2通りで、相手がメタデータをURLで公開している場合はそのURLを購読し、公開していない場合はXMLファイルをダウンロードしてアップロードします。
URLで購読できる場合は、相手側で証明書などが更新されても自動で追従できる利点があります。
ACSエンドポイントとエンティティIDの指定
メタデータを使わず値を個別に入力する場合に鍵となるのが、ACS（アサーションコンシューマーサービス）エンドポイントとエンティティIDです。ACSエンドポイントは、IdPが発行したSAML応答の送信先となるSP側のURLです。エンティティIDは、SPを一意に識別する名前で、IdPはこの値で相手を見分けます。
値そのものは製品ごとに決まった形式になっており、たとえばAmazon Cognitoでは、ACSに「https://{ユーザープールのドメイン}/saml2/idpresponse」を、SPのエンティティID（オーディエンスURI）に「urn:amazon:cognito:sp:{ユーザープールID}」を設定します。
署名証明書（X.509）の設定
IdPはSAML応答に署名し、SPはその署名を検証して応答が本物であることを確かめます。この署名に使われるのがX.509形式の証明書です。IdP側で発行した署名用証明書（公開鍵）をSPに登録しておくことで、SPは受け取ったアサーションがそのIdPから発行された正当なものかを判断できます。
Microsoft Entra IDでは、IdP側の「SAML トークン署名証明書」をダウンロードしてSPに渡す形で設定します。証明書には有効期限があるため、入れ替えの運用まで含めて押さえておくことが大切です。
NameID・属性マッピングの設定
IdPが送るNameIDや属性を、SP側のユーザー項目にひも付ける作業が属性マッピングです。たとえばAmazon Cognitoでは、ユーザープールの必須属性であるemailに対して、SAMLアサーションのemail値（クレーム）を指定します。
Microsoft Entra IDでは、SAML連携で必ず必要になるNameID（名前識別子）属性や、各種属性・クレームをアプリの要件に合わせて設定します。
NameIDには永続的な識別子（persistent）やメールアドレス形式など複数の形式があり、SPが期待する形式に合わせることが値のずれを防ぐポイントです。指定する値がSP側の期待とずれると、認証は成立してもユーザーを特定できずにエラーになります。
出典・参考資料（2件）
設定項目と入力値の対応（基盤をまたいだ早見表）
設定項目はどの基盤でも共通ですが、どちら側で設定するか、画面での呼び方や入る値は製品ごとに異なります。代表的な設定項目について、どちら側で設定するものかと、Amazon Cognito・Microsoft Entra IDでの指定の例を並べると、次のように整理できます。
| メタデータ | エンティティID | ACSエンドポイント | 署名証明書（X.509） | NameID・属性（クレーム） | |
|---|---|---|---|---|---|
| どちら側で設定するか | IdP・SPが相互に交換 | SPを識別する値（SP側が持つ） | SP側のURL（IdPはここへ送る） | IdPが署名し、SPが検証用に登録 | IdPが送り、SPが対応づけ |
| 内容 | 相手の構成情報（エンティティID・エンドポイント・証明書）を取り込み、自分の分を渡す | SPを一意に識別する名前。IdPはこの値で相手を見分ける | IdPが発行したSAML応答（アサーション）の送信先 | IdPの署名用証明書（公開鍵）をSPへ渡す | ユーザーを識別する値（NameID）とメールアドレスなどの属性をアサーションに載せる |
| 製品の画面での例 | Cognito（SP側の例）: 相手IdPのメタデータURLを購読、またはXMLをアップロード Entra ID（IdP側の例）: 自分のフェデレーションメタデータXMLを公開してSPに渡す | Cognito（SP側の例）: urn:amazon:cognito:sp:{ユーザープールID} Entra ID（IdP側の例）: 相手SPの「識別子 (エンティティ ID)」を登録 | Cognito（SP側の例）: https://{ユーザープールのドメイン}/saml2/idpresponse Entra ID（IdP側の例）: 相手SPの「応答 URL (Assertion Consumer Service URL)」を登録 | Entra ID（IdP側の例）: 「SAML トークン署名証明書」をダウンロードしてSPに渡す Cognito（SP側の例）: 相手IdPのメタデータから取り込む | Cognito（SP側の例）: email属性をSAML属性名にマッピング Entra ID（IdP側の例）: 「Name ID」と属性・クレームを設定 |
※ 画面名・入力値は各社の公式ドキュメントに基づく例です。利用する基盤やバージョンにより名称や手順が異なる場合があるため、実際の設定時は各社の最新情報をご確認ください。
Oktaのように、自社の基盤をSP側にして外部のSAML 2.0 IdPを追加する構成でも、設定の流れは同じです。IdPのメタデータを取り込み、属性のマッピングを設定し、必要に応じてサインインに失敗したときのエラーページを指定します。
出典・参考資料（1件）
出典・参考資料（2件）
認証が通らない定番原因と対処（トラブルシュート）
設定したはずなのにSSOが通らない、という事態はSAML連携でよく起こります。原因の多くは、署名・時刻・証明書・属性値といった、互いの前提がわずかにずれている点に集約されます。ここでは、起こりやすい原因と症状、確認のポイントを整理します。
原因と対処の早見表
| 署名アルゴリズムの不一致・弱いアルゴリズムの使用 | IdPとSPのサーバー時刻のずれ（クロックスキュー） | 署名証明書の期限切れ・入れ替え漏れ | NameID・属性値の不一致 | HTTPSを使っていない | メタデータの変更が反映されていない | |
|---|---|---|---|---|---|---|
| 主な症状 | 署名の検証に失敗し（signature validation error など）認証が通らない | アサーションの有効期間（Conditions の NotBefore・NotOnOrAfter。多くは数分）を外れ、期限切れで認証に失敗する | それまで動いていたSSOがある日突然止まる | 認証は成立してもユーザーを特定できずエラーになる | 通信が受け付けられない | 設定変更後にSSOが止まる |
| 確認・対処 | IdPとSPで署名アルゴリズムを揃える。SHA-1は非推奨のため、より安全なSHA-256などへ移行する | 両サーバーの時刻をNTPなど正しいタイムソースに同期する。実装によっては許容するずれ（スキュー）を数分まで設定できる | 証明書の有効期限を管理し、更新時はSP側へ新しい証明書を登録する | IdPが送るNameID・メールアドレスの値を、SP側のユーザー識別子と一致させる | SAMLのやり取りはHTTPSで行う | エンドポイントや証明書を変えたら、相手側に渡したメタデータも更新する |
※ 一般的に起こりやすい原因の整理です。実際の切り分けは利用する基盤のログ・エラー表示を確認してください。
署名検証・HTTPS・リプレイ防止のチェックポイント
公式ドキュメントでも、安全な連携のための前提がいくつか明示されています。Microsoft Entra IDのドキュメントは、トランスポートにHTTPSを要求すること、IdP側サーバーの時刻を正しいタイムソースに同期すること（不正確な時刻はフェデレーションログインの失敗につながると注意しています）、そして署名アルゴリズムについて次のように案内しています。
セキュリティを向上させるために SHA-1 アルゴリズムは非推奨です。 SHA-256 などのより安全なアルゴリズムを使用してください。
出典：シングル サインオンに SAML 2.0 ID プロバイダーを使用する｜Microsoft Learn
あわせて、盗み取ったアサーションを使い回すリプレイ攻撃への備えも欠かせません。SAMLでは、アサーションの有効期間や一度きりの利用を検証することで、この種の攻撃を防ぎます。
署名の検証が有効か、通信がHTTPSか、リプレイ対策やNameID・属性の値の整合が取れているか。これらは認証が通らないときにまず確認したい基本です。
連携後の動作確認（SSOが成立するかの検証）
設定が終わったら、実際にSSOが成立するかの検証が欠かせません。テスト用のユーザーで、SP側のサインオンURLからログインを試し、IdPでの認証を経てサービスに入れるかを確かめるのが基本です。
ログインだけでなく、ログアウトの挙動もあわせて確認しておきましょう。SAML 2.0には、IdPでの1回のログアウト操作で連携先のSPのセッションもまとめて終了させるシングルログアウト（SLO）という仕組みがあります。使う場合は、ログイン側とは別にSLO用のエンドポイントを設定します。ただしSP側が対応していないこともあるため、ログアウトが全サービスに行き渡るかはテストで確かめておくと安心です。
うまくいかないときは、IdP・SPそれぞれのログやエラー表示から、どの段階（リダイレクト・署名検証・ユーザー特定）で止まっているかを切り分けると、原因に早くたどり着けます。
本番利用の前にテスト環境で一通り流しておくと、証明書や属性の設定ミスを早い段階で見つけられます。
出典・参考資料（2件）
SAML・OAuth 2.0・OpenID Connectの違い
認証連携の話をすると、SAMLと並んでOAuth 2.0やOpenID Connectという言葉も出てきます。これらは目的が異なる仕様で、混同すると「どれを使えばよいか」で迷いがちです。仕様の位置づけを押さえると、SAMLを選ぶべき場面かどうかを判断しやすくなります。
OAuth 2.0は、仕様の定義そのものが示すとおり「認可（アクセス権限の委譲）」のための枠組みです。OpenID Connectは、そのOAuth 2.0の上に本人確認（認証）の層を加えた仕様です。
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service（OAuth 2.0は、第三者アプリケーションがHTTPサービスへの限定的なアクセスを得ることを可能にする認可フレームワーク）
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol（OpenID Connect 1.0は、OAuth 2.0プロトコルの上に載せるシンプルなアイデンティティ層）
出典：The OAuth 2.0 Authorization Framework (RFC 6749)｜IETF ／ OpenID Connect Core 1.0｜OpenID Foundation
一方のSAML 2.0は認証とフェデレーションのための規格で、XMLをベースにしています。3つの関係を表にまとめると、次のようになります。
| SAML 2.0 | OAuth 2.0 | OpenID Connect | |
|---|---|---|---|
| 主な目的 | 認証（本人確認）とフェデレーション | 認可（アクセス権限の委譲） | 認証（OAuth 2.0の上に本人確認を追加） |
| データ形式 | XML | アクセストークン | IDトークン（JWT） |
| 標準化 | OASIS（2005年承認） | IETF（RFC 6749） | OpenID Foundation |
既存のエンタープライズ向けSaaSと連携する場面ではSAML 2.0が、モバイルアプリやAPIへのアクセス権限の受け渡しではOAuth 2.0やOpenID Connectが選ばれやすい、という使い分けが基本になります。
一括ダウンロードする
SAML 2.0のIdPとして使えるID基盤の選び方
ここまでは、すでにIdPがある前提で設定の要点を見てきました。一方で、自社にSAML 2.0に対応したID基盤がまだない、あるいは今の基盤が対応しているか分からない、という場合もあります。その場合は、SAML 2.0のIdPとして使えるID基盤（IDaaS）を選ぶところから始めます。
選び方の軸やメリット、導入事例まで含めてIDaaS全体をじっくり比較検討したい方は、主要サービスをまとめて比較した以下の記事もあわせてご覧ください。
IdP（ID基盤）を選ぶときの軸
IdPとして使うID基盤を選ぶときは、次の観点を自社の状況に当てはめて見ていくのが基本です。まず、連携したいサービスがSAML 2.0に対応しているか（必要に応じてOpenID Connectへの対応も）です。次に、ログインの安全性を高める多要素認証（MFA）を備えているか。
さらに、入社・異動・退職にあわせてアカウントを自動で作成・更新・削除するプロビジョニング（SCIMやJIT）に対応しているかは、運用の手間を大きく左右します。加えて、既存のActive Directoryや人事システムとの連携のしやすさ、国産かどうか、無料プランやセルフホストといった始めやすさも、自社の体制に合わせて見ていきます。
選ぶ軸のうち多要素認証（MFA）について、認証方式ごとの安全性や料金を比べて単体でも深掘りしたい場合は、MFAシステムを認証方式・料金・タイプ別に比較した以下の記事が参考になります。
多要素認証（MFA）システムおすすめ17選を徹底比較｜認証方式・料金・タイプ別の選び方
ID とパスワードだけのログインは、もはや「鍵をかけていない」のと同じ状態に近づいています。攻撃者は流出したパスワードのリストを使い回し、本物そっくりの偽サイトで認証情報を抜き取り、正規利用者になりすまして社内システムやクラウドサービスへ侵…
ここからは、SAML 2.0のIdPとして使える代表的なID基盤を紹介します。ここで挙げるのは認証を担うIdPとして使える基盤で、先ほど設定例に挙げたAmazon CognitoのようなSP側の受け手とは役割が異なります。
資料をまとめて請求できるサービスから、無料プランで始められる国産サービス、自社で構築するオープンソースまで、選び方の軸が異なるものを取り上げます。
| サービス名 | CloudGate UNO | Okta | Microsoft Entra ID | HENNGE One | トラスト・ログイン byGMO | Keycloak |
|---|---|---|---|---|---|---|
| 提供形態 | 国産・マネージド（IDaaS） | 外資・マネージド（IDaaS） | 外資・マネージド（IDaaS） | 国産・マネージド（IDaaS） | 国産・マネージド（IDaaS） | OSS・セルフホスト |
| SAML 2.0 IdP対応 | ●OIDC・フォームベースも対応 | ●OIDCも対応 | ●OIDCも対応 | ● | ●OIDCも対応 | ●OIDC・OAuth 2.0も対応 |
| 多要素認証（MFA） | ●FIDO2/パスキー・生体認証・OTP | ●Adaptive MFA・FIDO2・FastPass | ●パスキー・Windows Hello・条件付きアクセス | ●OTP・プッシュ承認（HENNGE Lock） | ●OTP・パスキー(FIDO2)・プッシュ通知 | ●パスキー・TOTP（Google Authenticator等） |
| プロビジョニング | ●アカウント自動化・AD連携 | ●SCIM・HR連携（上位プラン） | ●SCIM 2.0・HR連携（P1以上） | △JIT対応（対応SaaSは限定的） | ●SCIM・対応アプリ100超（SaaS管理） | △SCIM（Preview）・LDAP/AD連携 |
| 無料で始める | 30日間無料トライアル | 30日間無料トライアル | 無料プランあり（Entra ID Free） | 要お問い合わせ | 無料プランあり（SSOフリー） | OSSで無償（セルフホスト） |
| 月額費用（目安） | 400〜600円/ユーザー（税抜） | 940円〜/ユーザー（年契約） | 無料〜1,499円/ユーザー（P1 1,049円・P2 1,499円） | 400円〜/ID（IdP、税抜） | 0円〜（SSOプロ 300円/ID・税抜） | 無償（運用・インフラ費は自社負担） |
| 詳細情報 | 公式資料を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る |
※ 対応状況・料金は各社公式情報に基づく目安です（2026年11月時点）。税区分・最新のプラン・料金は各社公式サイトでご確認ください。
上の表では月額費用の目安を示しましたが、初期費用や最小契約人数まで含めた実額で各社を比較したい場合は、公式料金ページ準拠でまとめた以下の記事が役立ちます。
1. CloudGate UNO（株式会社インターナショナルシステムリサーチ）
CloudGate UNOは、株式会社インターナショナルシステムリサーチが提供する国産のID基盤です。シングルサインオン・多要素認証・アクセス制限・ID管理を1つにまとめており、SAML 2.0のIdPとして各種クラウドサービスと連携できます。公式のSSO連携仕様では、SAML 2.0・OpenID Connect・フォームベース認証に対応するとされています。
FIDO2やパスキー、Windows Helloなどの端末の生体認証にも対応し、パスワードに依存しないログインを組みやすいのも特徴です。外部のIdPと連携するオプションも用意されており（Enterprise Plus・Smart Packの有償オプション）、既存の認証基盤と組み合わせた構成も検討できます。
公式サイトでは導入1,400社以上と案内されています（2026年11月時点）。国内に開発・サポート体制を持つ国産のID基盤を求める企業に向いた選択肢です。
出典・参考資料（1件）
IdPが備える多要素認証の方式ごとに、安全性にどのような差があるのか。同社は独自インタビューで次のように述べています。
当社が採用しているパスキーのパスワードレス認証は、フィッシング攻撃に対して非常に強い耐性を持ちます。SMS認証やワンタイムパスワードなどの一般的な多要素認証を突破する攻撃手法が顕在化する中、より安全な認証環境を提供します。
2. Okta（Okta Japan株式会社）
Oktaが提供するWorkforce Identity Cloudは、従業員や委託先など「働く人」のアイデンティティを管理するクラウド型のID基盤です。シングルサインオン、多要素認証（Adaptive MFAを含む）、ユーザーディレクトリ（Universal Directory）、IDライフサイクル管理を統合的に備えています。
SCIM標準や各種アプリ連携、Active Directory連携により、入社・異動・退職に伴うアカウントのプロビジョニング／デプロビジョニングを自動化できる点が強みです。外部のSAML 2.0 IdPを足す構成（inbound SAML）にも対応しており、幅広いSaaSとの連携に対応します。グローバルに展開する組織での導入実績があります。
出典・参考資料（1件）
3. Microsoft Entra ID（Microsoft Corporation）
Microsoft 365やAzureの認証基盤を担うのが、Microsoft Entra ID（旧 Azure AD）です。クラウドベースのID・アクセス管理プラットフォームで、シングルサインオン・多要素認証・条件付きアクセス・パスワードレス認証に加え、アカウントの自動プロビジョニングを含むIDライフサイクル管理を提供します。
アプリケーション連携のギャラリーを通じてSAML 2.0やOpenID ConnectによるSSOを設定でき、IdPとしてもSPとしても構成できます。すでにMicrosoft 365やAzureを利用している組織では、追加導入なしに多要素認証やアカウント自動化まで利用できる構成になっている点が、導入のしやすさにつながります。
出典・参考資料（1件）
4. HENNGE One（HENNGE株式会社）
HENNGE Oneは、IDプロバイダーとしてのSSO・多要素認証・アクセス制御に、メールやエンドポイントのセキュリティを組み合わせた国産の統合基盤です。SAMLなどによるクラウドサービスへのシングルサインオンを提供し、連携するSaaSの数に応じた追加課金がない料金体系を打ち出しています。
SAMLで接続したサービスへのジャストインタイム（JIT）プロビジョニングに対応し、ユーザー情報を連携先へ同期するIDライフサイクル管理の自動化も進めています。IPアドレス制限やデバイス証明書によるアクセス制御も備えており、国内のサポート体制とあわせて検討しやすいサービスです。
出典・参考資料（1件）
5. トラスト・ログイン byGMO（GMOグローバルサイン株式会社）
トラスト・ログイン byGMOは、基本機能を無料プランから使い始められる企業向けのクラウド型ID基盤です。提供元はGMOグローバルサイン株式会社で、シングルサインオン、ID管理・プロビジョニング、多要素認証、アクセス制限、ログ・レポートを中核としています。SAML認証によるSSOに対応しています。
SaaS側のアカウントを自動で作成・更新・削除するIDプロビジョニング連携に対応するアプリも広げており、入退社・異動時のアカウント管理の自動化に役立ちます。電子認証局を運営するGMOグローバルサインのセキュリティ事業の一環で、まず無料で試してから拡張したい企業に向いています。
出典・参考資料（1件）
6. Keycloak（オープンソース／CNCFプロジェクト）
Keycloakは、Apache License 2.0で公開されているオープンソースのID・アクセス管理ソフトウェアです。特定の営利企業が販売するSaaSではなく、CNCF（Cloud Native Computing Foundation）配下のプロジェクトとしてコミュニティ主導で開発されています。SAML 2.0を標準で搭載しており、IdPとして利用できます。
自社のサーバーやコンテナ環境に構築して運用するセルフホスト型である点が、ほかのマネージド型サービスと大きく異なります。利用料がかからない一方で、サーバー構築・データベース・SSL・アップグレード・脆弱性対応は自社で担う前提です。
日本でも商用サポートやディストリビューションを提供するベンダーがあり、コストを抑えつつ自前で認証基盤を構築したい企業に向いています。
出典・参考資料（1件）
まとめ
SAML 2.0のIdPは、ユーザーを認証して署名付きのアサーションを発行する側で、それを受け取って検証するSPと役割を分担します。設定では、メタデータ・エンティティID・ACSエンドポイント・署名証明書・NameIDや属性のマッピングという共通の項目を、利用する基盤の呼び方に合わせて埋めていきます。
認証が通らないときは、署名アルゴリズム・時刻のずれ・証明書の期限・属性値の不一致・HTTPSといった定番の原因から切り分けると、早く解決にたどり着けます。
自社にIdPがまだない場合は、SAML 2.0への対応・多要素認証・プロビジョニング・既存システムとの連携のしやすさが選び方の軸になります。国産のマネージドサービスから無料で始められるもの、セルフホストのオープンソースまでが選択肢です。各サービスの資料をまとめて取り寄せ、自社の環境に合う基盤を見極める材料にしてください。
一括ダウンロードする
よくある質問（FAQ）
Q. SAML 2.0のIdP（アイデンティティプロバイダー）とは何ですか？
A. SAML 2.0のIdPとは、ユーザーを認証し、その結果を署名付きのアサーションとしてサービス側（SP）に渡す役割を担う側です。利用者が1つのID基盤でログインすれば複数のサービスに入れるシングルサインオン（SSO）を実現するための中心的な存在で、SAML 2.0はこのIdPとSP、アサーションの関係を定めたXMLベースの標準規格です。
Q. SAML 2.0のIdPとSP（サービスプロバイダー）は何が違いますか？
A. IdPはユーザーを認証する側、SPは認証をIdPに委ねてサービスを提供する側です。IdPが「この人は本人です」という情報を署名付きのアサーションとして発行し、SPはそれを検証してアクセスの可否を決めます。設定時は、自社がIdPとSPのどちらを担うのかを最初に整理すると、どの値をどこに入れればよいかが分かりやすくなります。
Q. SAMLとOAuth 2.0・OpenID Connectはどう使い分ければよいですか？
A. 既存のエンタープライズ向けSaaSとのSSOにはSAML 2.0、モバイルアプリやAPIへのアクセス権限の受け渡しにはOAuth 2.0やOpenID Connectが向いています。SAMLとOpenID Connectは「認証（本人確認）」、OAuth 2.0は「認可（アクセス権限の委譲）」が主な目的で、SAMLはXML、OAuth系はトークン（JWTなど）とデータ形式も異なります。
連携相手がどの仕様に対応しているかで選ぶのが基本です。
Q. SAML 2.0とSAML 1.xはどちらを使えばよいですか？
A. これから連携を組むなら、現在はSAML 2.0を使うのが基本です。SAML 2.0はOASISが2005年に承認したオープン標準で、多くのクラウドサービスやID基盤がこのバージョンに対応しています。旧来の1.xとは互換性がないため、IdPとして使う基盤も連携先のサービスも、SAML 2.0に対応したものを選びます。
Q. SAML 2.0は今でも使われていますか？
A. SAML 2.0は現在もエンタープライズ向けSaaSのシングルサインオンで広く使われている標準規格です。主要なクラウドサービスやID基盤（IDaaS）の多くがSAML 2.0に対応しており、社内の複数SaaSを1つのID基盤でまとめてログインさせたい場面では今も定番の選択肢です。新しいアプリやAPIへのアクセス連携では、OpenID ConnectやOAuth 2.0も併用されます。
Q. SAML認証は安全ですか？どんな点に注意すればよいですか？
A. SAMLはアサーションへの署名やHTTPSでの通信を前提に設計された仕組みで、これらを正しく運用すれば安全に利用できます。一方で、署名の検証を有効にする、通信をHTTPSで行う、弱い署名アルゴリズム（SHA-1）を避けてSHA-256などへ移行する、といった運用を怠ると、なりすましや改ざんのリスクが生じます。安全性は仕様そのものだけでなく、設定と運用に依存します。
Q. SAML連携で認証が通らないときは何を確認すればよいですか？
A. 署名アルゴリズムの不一致、IdPとSPのサーバー時刻のずれ、署名証明書の期限切れ、NameID・属性値の不一致、HTTPS未使用が、認証が通らない定番の原因です。認証自体は成立してもユーザーを特定できずにエラーになる場合は、IdPが送るNameIDや属性の値がSP側の期待と一致しているかを確認します。
IdP・SPそれぞれのログで、どの段階（リダイレクト・署名検証・ユーザー特定）で止まっているかを切り分けると、原因にたどり着きやすくなります。
Q. 自社にSAML 2.0対応のIdPがない場合はどうすればよいですか？
A. 自社にIdPがない場合は、SAML 2.0のIdPとして使えるID基盤（IDaaS）を導入するのが現実的です。マネージド型のクラウドサービスなら、サーバーの構築や証明書の運用を自前で抱えずに、SSOや多要素認証を始められます。無料プランから試せる国産サービスや、自社サーバーに構築するオープンソースまで選択肢があり、自社の体制と予算に合わせて選ぶとよいでしょう。
Q. SAML 2.0のIdPとして使うID基盤は何を基準に選べばよいですか？
A. 連携したいサービスがSAML 2.0（必要に応じてOpenID Connect）に対応しているか、多要素認証やプロビジョニング（SCIM／JIT）を備えているか、既存システムと連携しやすいかが主な軸です。加えて、入退社・異動に伴うアカウントの発行・削除を自動化できるか、国産かどうか、無料プランやセルフホストで始めやすいかも、自社の運用体制に合わせて見ておきたいポイントです。
SAML 2.0対応のID基盤（IDaaS）の資料を一括チェック
MCB FinTechカタログでは、SAML 2.0のIdPとして使えるID管理システムの最新資料を無料で一括請求できます。SSO・多要素認証・プロビジョニングへの対応や料金をまとめて比較できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
