マーケティングツールにおけるSCIMとSSO：エンタープライズITが実際に求めること

SSO/SCIMの要件は、２つの形で届きます。セキュリティアンケートに埋め込まれたものとして届く場合があります。「御社のアプリケーションはSAML 2.0またはOIDCシングルサインオンをサポートしていますか？SCIM 2.0による自動プロビジョニングはサポートしていますか？」という問いです。あるいは、ITからの直接指示として届く場合もあります。個人データを扱うベンダーはすべて、企業のIdPを通じて認証しなければならない、スタンドアロンのパスワードログインも共有認証情報も例外はない、というものです。

どちらの場合も、結果は同じです。マーケティングツールが企業のアイデンティティプロバイダーと連携するか、あるいは置き換えられるかのどちらかです。

マーケティングツール - URLショートナー、キャンペーントラッカー、UTMマネージャー - は今、このレビューを受けています。マーケティングチームはクリックイベントレイヤーでPIIを扱っているからです。ユーザーのIPアドレス、ユーザーエージェント、リファラーを記録する短縮リンクは個人データを処理しています。その処理はIdPが管理するアクセスモデルの対象となります。

この記事は調達チェックリスト版です。SSOとSCIMが何を要求するか、マーケティングSaaSのどこが不足しているか、そしてベンダーとのディスカバリーコールに持ち込むべき５つの質問を説明します。

TL;DR#

• SAML 2.0とOIDCはIdPの世代が異なるため両方が存在します。レガシーエンタープライズはSAMLを使用し、モダンなIdPはOIDCをネイティブで話します。一方だけをサポートするベンダーは市場の半分を逃しています。
• SCIM 2.0はプロビジョニングレイヤーです。アカウントを作成し、更新し、そして重要なことにデプロビジョニングします。JITプロビジョニングは初回ログイン時にアカウントを作成しますが、デプロビジョニングは行いません。監査の観点では、SCIMが要件となります。
• ほとんどのマーケティングツールはSSOをベースプランより月額500〜2,000ドル高いエンタープライズティアに限定しています。追加料金なしでBusinessティアにSSOを含めるベンダーは例外的な存在です。
• 重要な調達質問：SAMLメタデータURL、SCIMエンドポイントURL、ベアラートークンのローテーション周期、デプロビジョニングのレイテンシー、そしてIdPグループからロールへのマッピング。

SAML 2.0とOIDC：なぜ両方がまだ存在するのか#

SAML 2.0は2005年にOASISが公開したXMLベースのフェデレーション標準です。IdPは署名済みのSAMLレスポンスをSPのAssertionConsumerService URLにポストします。SPはIdPの証明書に対して署名を検証し、サブジェクトと属性ステートメントを取り出し、セッションを作成します。

OIDCはOAuth 2.0上に構築されており、同じ役割をJSONで処理します。IdPはSPがIdPのJWKSエンドポイントに対して検証するJWT（IDトークン）を発行します。

両方が共存しているのは、レガシーエンタープライズのIdP - オンプレミスのAD FS、古いOkta設定、Ping Federate - がSAMLをプライマリとして使用しているからです。Google WorkspaceやJumpCloudのモダンスタックのようなクラウドネイティブなIdPはOIDCをネイティブで話し、SAMLをセカンダリプロトコルとして持ちます。混在したエンタープライズ環境では両方が動作しています。

SP起点とIdP起点のフロー。 SP起点のログインが標準です。ユーザーがアプリにアクセスし、アプリがIdPにリダイレクトし、IdPが認証してポストバックします。IdP起点はSPのリダイレクトをスキップします。ユーザーがOktaまたはEntraのダッシュボードのタイルをクリックすると、IdPが未要求のアサーションをSPに直接送信します。両方のフローが機能する必要があります。IdP起点の実装はセキュリティ的に難しく（SPがバインディングとデスティネーション属性を検証しない場合はCSRFスタイルのインジェクションリスクがあります）、SP起点のみをサポートするベンダーは、ITが会社のダッシュボードにアプリタイルを追加しようとすると失敗します。

SCIM 2.0：プロビジョニングレイヤー#

SCIM 2.0 - RFC 7644 - はSaaSアプリケーション全体でユーザーアカウントのライフサイクル管理を自動化します。３つのコアオペレーション：

プロビジョニング： ユーザーの属性と共に POST /Users します。SPはアカウントを作成して新しいIDを返します。

更新： JSONパッチペイロード（表示名、部署、ロール、IdPが権威を持つもの）と共に PATCH /Users/:id します。

デプロビジョニング： DELETE /Users/:id（ハード削除）または { "active": false } を含む PATCH /Users/:id（ソフトデアクティベート、より一般的なエンタープライズパターン）。

デプロビジョニングは監査上クリティカルな部分です。オーファンアカウント - 退職した従業員のアカウントで、ITが忘れたか、ベンダーが自動デプロビジョニングをサポートしていないために削除されなかったもの - は一貫した侵害の攻撃面となります。ISO 27001のコントロールA.9.2とSOC 2のCC6.2はどちらも、アクセスを削除するための文書化されたプロセスを要求しています。手動でのデプロビジョニングは予測可能な形で失敗します。オフボーディングチケットが見落とされ、アカウントがアクティブなまま残り続けます。SCIMはデプロビジョニングを自動化し監査可能にします。IdPがデアクティベートリクエストを送信し、SPがそれを記録し、そのログが監査証跡となります。

マーケティングツールのギャップ#

エンタープライズSaaSのほとんどのカテゴリ - HR、CRM、ITSM、コードホスティング - はミッドマーケットのチームが実際に購入できるプランでSSOを提供しています。マーケティングツールは遅れをとっています。一貫して見られるパターン：SSOは「エンタープライズ」機能として掲載され、Businessプランより月額500〜2,000ドル高い別のティアで価格設定されています。これはSSOが大規模組織向けのプレミアムアップセルであり、基本的なセキュリティコントロールではないという意味合いを持ちます。

このフレームは、エンタープライズITがベンダーを評価する方法とますます相容れなくなっています。マーケティングツールが識別可能なユーザーのクリックデータを扱う場合、カテゴリに関わらず会社のアクセスガバナンスプログラムのスコープに入ります。プレミアムティアの後ろにSSOをゲートすることは、マーケティングチームがIdPの外でツールを運用することを意味します - これはITが防ごうとしている結果です。

追加料金なしでBusinessティアにSSOを含めるベンダーは例外です。URLショートナーの中では：ElidoはWorkOS経由でBusinessプランにSAML/OIDC SSOとSCIMプロビジョニングを含んでいます。Bl.inkはTeamプランにSSOを含んでいます。Loops（メール自動化）とCustomer.ioはどちらも別のエンタープライズゲートなしでBusinessにSSOを提供しています。

ベンダーが「エンタープライズ価格についてはお問い合わせください」の下にのみSSOを掲載している場合、そのツールがスタックに存在する間、すべての従業員の異動について手動でのデプロビジョニングワークフローが必要になります。

IdPのランドスケープと互換性#

６つのIdPがエンタープライズITを支配しています：

Oktaは米国エンタープライズで最も一般的なクラウドIdPです。OktaはSAML 2.0、OIDC、そして洗練されたSCIMインターフェースを提供しています。SCIMが確認されたOkta Integration Networkに掲載されているベンダーは、ITチームの設定が文書化されテスト済みであることを意味します。そうでなければカスタム統合を作成することになります。

Microsoft Entra ID（旧Azure AD）はMicrosoft 365を利用する企業のデフォルトです。そのSCIMプロビジョニングエージェントはアプリケーションエンドポイントをポーリングします。デフォルトの間隔は40分なので、デプロビジョニングは即時ではありません。調達レビューで浮き上がらせる価値があります。

JumpCloudはSAML 2.0、OIDC、SCIM 2.0をサポートしています。オンプレミスのADなしでクラウドディレクトリを望むミッドマーケットチームに人気があります。

Google WorkspaceはOIDCをネイティブで使用します。SAML 2.0はレガシーアプリの互換性のために利用可能です。サードパーティのSCIM統合は標準のRFC 7644パスに従います。

OneLoginはSAML 2.0、OIDC、SCIMを維持しています。Oktaが市場を統合する前に標準化したミッドマーケット組織に一般的です。

WorkOSはSaaSアプリケーションがSSOとSCIMを実装するために使用するベンダーサイドのプラットフォームです（エンドユーザーのIdPではありません）。「WorkOSを使用しています」と言うベンダーは、Okta、Entra、JumpCloud、Google、OneLoginとの互換性を同時に表明しています。ElidoのSSO統合はWorkOS上に構築されています。ITにとっての実際的な意味：OktaまたはEntraをSCIMエンドポイントに向けることができれば、ベンダー固有の設定作業なしに統合が機能します。

JITプロビジョニングとSCIMプロビジョニング#

ジャストインタイムプロビジョニングは、ユーザーがSSO経由で初めて認証した際にユーザーアカウントを作成します。事前プロビジョニングステップは不要で、属性はSAMLアサーションまたはOIDCトークンから来ます。

JITはプロビジョニングの半分をきれいに解決します。問題はデプロビジョニングの半分です。ユーザーがIdPから削除されると、SSOセッションが機能しなくなります。しかし、SaaSアプリケーション内のアカウントは残存します。長期間有効なAPIトークンはまだ機能する可能性があります。アカウントはアクティブユーザーの監査には表示されます。

ISO 27001またはSOC 2環境では、JIT単独では不十分です。監査の質問は「この従業員はログインできるか？」ではなく「アクセスが終了したという監査可能な記録があるか？」です。JITはそのレコードを生成しません。SCIMは生成します。DELETE または { "active": false } イベントはIdPとSPの両方でログに記録され、タイムスタンプが付き、クエリ可能です。

ベンダーレビューでデプロビジョニングの証拠が必要な場合は、SCIM 2.0デプロビジョニングがサポートされているかどうかを具体的に尋ねてください。質問がSCIMについてのものなのに「はい、SSOをサポートしています」と答えるベンダーは別の質問に答えています。

ロールマッピング：IdPグループからSaaSロールへ#

標準的なパターン：IdPには２つのグループがあります - marketing-team（全スタッフ）と marketing-leads（チームリード）。SaaSアプリケーションには２つのロールがあります：MarketerとAdmin。ITチームが一度マッピングを設定します：marketing-team → Marketer、marketing-leads → Admin。誰かがグループ間を移動すると、次のSCIM同期が自動的にロールを更新します。

SCIMは Groups リソース（GET /Groups、POST /Groups、PATCH /Groups/:id）を通じてグループメンバーシップを運びます。すべてのSCIM実装がグループ同期をサポートしているわけではありません。一部のベンダーはユーザープロビジョニングのみを実装しており、ロールマッピングにはユーザーごとの手動設定が必要になります。SCIMグループプッシュがサポートされているか、ロールマッピングがサポートチケットなしで管理者が設定できるかをベンダーに具体的に確認してください。

EU拠点の組織にとって、SCIMを通じて流れるIdPグループメンバーシップデータはそれ自体がGDPR第4条第1項の個人データを構成する可能性があります。マーケティング向けEUデータレジデンシーの記事では、DPAがアイデンティティデータレイヤーについて何を述べるべきかを扱っています。SaaSベンダーはそのデータの処理者であり、DPAはそれを明示的に扱うべきです。

調達で尋ねるべきこと#

マーケティングツールのSSO/SCIM統合が半日のIT設定で済むか、数週間のプロジェクトになるかを決める５つの質問：

SAMLメタデータURL。 ベンダーはSPメタデータ（エンティティID、ACS URL、署名証明書）を指す静的なURLを提供できますか？これがOktaやEntraに貼り付けるものです。顧客ごとの手動メタデータ入力はレッドフラグです。

SCIMエンドポイントと認証方法。 SCIMベースURLは何ですか？ベアラートークンが標準です。OAuth 2.0クライアントクレデンシャルはより複雑です。トークンのローテーション周期は何ですか？ローテーションしない静的トークンはリスクです。

デプロビジョニングのレイテンシー。 IdPが PATCH /Users/:id { "active": false } または DELETE を送信すると、どのくらいの速さでアクセスが終了しますか？EntraのプロビジョニングインターバルはIdP側でデフォルト40分です。ベンダーはリクエストが届いた後の処理ウィンドウにコミットすべきです。両方のレイテンシーの組み合わせがSOC 2監査人が尋ねることです。

グループプッシュのサポート。 SCIMグループプッシュはSCIMユーザープロビジョニングとは別です。ベンダーがユーザー同期のみを実装している場合、ロールマッピングにはユーザーごとの手動設定が必要です。具体的に確認してください。

IdPタイルのサポート。 アプリケーションをOktaまたはEntraのダッシュボードにタイルとして追加し、IdP起点のログインをサポートできますか？

コンプライアンスのオーバーレイ#

ISO 27001 Annex AのコントロールA.9.2は、ユーザーアクセス権が文書化されたプロセスに従って付与、レビュー、終了されることを要求しています。A.9.3は、ユーザーが自分に割り当てられたクレデンシャルでのみ認証することを要求しています。SCIMは「HRオフボーディング」と「SaaSアクセスの取り消し」を手動手順なしで結びつける運用メカニズムです。

SOC 2のCC6.2は、エンティティがアクセスを付与する前にユーザーを登録して承認することを要求しています。CC6.3は定期的なアクセスレビューと削除を要求しています。SCIMデプロビジョニングログ - IdPがSaaSアプリケーションにユーザーのデアクティベートまたは削除を指示した時刻のタイムスタンプ付き記録 - は、スコープ内の各アプリケーションについてCC6.3コンプライアンスを示す監査証跡です。

ElidoはISO 27001認証を取得しています。SOC 2 Type IIは進行中で、2026年下半期を目標としています。アイデンティティの姿勢 - WorkOS経由のSAML/OIDC、SCIM 2.0デプロビジョニング、グループベースのロールマッピング - はトラストページとsolutions/enterpriseのブリーフに文書化されています。BAAはHIPAA関連ワークフロー向けにBusinessプランで利用可能です。

GDPRとURLショートナーのコーナーストーンでは第28条と第32条を完全に扱っています。SSOとSCIMはArticle 32の技術的コントロールです - SSOによる認証、SCIMによるデプロビジョニング - スタンドアロンの機能ではありません。これらはDPOがArticle 32のレビュー中に評価するセキュリティポスチャーのコンポーネントです。

/pricingはプランの内訳とSSO/SCIMが含まれる場所を示しています。/solutions/complianceは購入チーム向けのサマリーです。デプロビジョニング証拠の会話は、DPA、サブプロセッサーリスト、データレジデンシーのコミットメントと同じ調達コールに属します - これらがマーケティングツールがセキュリティレビューを通過するかどうかを決める質問です。

NIST SP 800-63-3 Digital Identity Guidelines（2026年5月12日アクセス）は、多くのエンタープライズIdPポリシー要件の基礎となる保証レベルと認証子タイプの権威あるフレームワークです。フェデレーションセクション - 800-63C - はSAMLおよびOIDCの統合設定に直接関連します。