The SSO/SCIM requirement arrives in one of two ways. Sometimes it comes embedded in a security questionnaire: "Does your application support SAML 2.0 or OIDC single sign-on? Does it support SCIM 2.0 automated provisioning?" Sometimes it arrives as a direct instruction from IT: any vendor that handles personal data must authenticate through the corporate IdP. No standalone password login, no shared credentials, no exceptions.
Either way, the consequence is the same. Your marketing tool either integrates with the company's identity provider or it gets replaced.
Marketing tools — URL shorteners, campaign trackers, UTM managers — are arriving at this review now because marketing teams handle PII in the click-event layer. A short link that logs a user's IP, user-agent, and referrer is processing personal data. That processing belongs in the IdP-governed access model.
This post is the procurement-checklist version: what SSO and SCIM require, where marketing SaaS falls short, and the five questions to bring to the vendor discovery call.
TL;DR#
- SAML 2.0 and OIDC serve different IdP generations — legacy enterprise runs SAML; modern IdPs speak OIDC natively. A vendor that supports only one is missing half the market.
- SCIM 2.0 is the provisioning layer: it creates accounts, updates them, and — critically — deprovisions them. JIT provisioning creates accounts on first login but does not deprovision. For audit, SCIM is the requirement.
- Most marketing tools gate SSO behind an enterprise tier priced at $500–2,000/month above the base plan. Vendors that include SSO on a Business tier without the upcharge are the exception.
- The procurement questions that matter: SAML metadata URL, SCIM endpoint URL, bearer token rotation cadence, deprovisioning latency, and IdP group-to-role mapping.
SAML 2.0 and OIDC: why both still exist#
SAML 2.0, published by OASIS in 2005, is an XML-based federation standard. The IdP posts a signed SAML Response to the SP's Assertion Consumer Service URL; the SP validates the signature against the IdP's certificate, extracts the subject and attribute statements, and creates a session.
OIDC, built on OAuth 2.0, handles the same job with JSON. The IdP issues a JWT (the ID token) that the SP verifies against the IdP's JWKS endpoint.
Both coexist because legacy enterprise IdPs — on-premises AD FS, older Okta configurations, Ping Federate — are SAML-primary. Cloud-native IdPs such as Google Workspace and JumpCloud's modern stack speak OIDC natively and carry SAML as a secondary protocol. Mixed enterprises run both.
SP-initiated vs IdP-initiated flow. SP-initiated login is the standard: user visits the app, app redirects to IdP, IdP authenticates and posts back. IdP-initiated skips the SP redirect — the user clicks a tile in the Okta or Entra dashboard and the IdP sends an unsolicited assertion directly to the SP. Both flows must work. IdP-initiated is harder to implement securely (CSRF-style injection risk if the SP doesn't validate the binding and destination attributes) and vendors that support only SP-initiated will fail when IT tries to add the app tile to the company dashboard.
SCIM 2.0: the provisioning layer#
SCIM 2.0 — RFC 7644 — automates user account lifecycle management across SaaS applications. Three core operations:
Provisioning: POST /Users with the user's attributes. The SP creates the account and returns the new ID.
Updates: PATCH /Users/:id with a JSON Patch payload — display name, department, role, whatever the IdP is authoritative for.
Deprovisioning: DELETE /Users/:id (hard delete) or PATCH /Users/:id with { "active": false } (soft deactivate, the more common enterprise pattern).
Deprovisioning is the audit-critical piece. Orphaned accounts — accounts belonging to former employees that were never terminated because IT forgot, or because the vendor doesn't support automated deprovisioning — are a consistent breach surface. ISO 27001 control A.9.2 and SOC 2 CC6.2 both require a documented process for removing access. Manual deprovisioning fails predictably: the offboarding ticket gets missed, the account sits active. SCIM makes deprovisioning automatic and auditable — the IdP fires the deactivate request, the SP logs it, and that log is the audit artefact.
The marketing-tool gap#
Most enterprise SaaS categories — HR, CRM, ITSM, code hosting — ship SSO on plans that a mid-market team can actually buy. Marketing tools have been slower. The pattern I see consistently: SSO is listed as an "Enterprise" feature, priced at a separate tier that costs $500–2,000/month above the Business plan. The implication is that SSO is a luxury upsell for large organizations, not a baseline security control.
That framing is increasingly incompatible with how enterprise IT evaluates vendors. When a marketing tool handles click data on identifiable users, it is in scope for the company's access governance programme regardless of category. Gating SSO behind a premium tier means the marketing team operates the tool outside the IdP — the outcome IT is trying to prevent.
Vendors that include SSO at the Business tier without a separate upcharge are the exception. Among URL shorteners: Elido includes SAML/OIDC SSO and SCIM provisioning on the Business plan via WorkOS. Bl.ink includes SSO on its Team plan. Loops (email automation) and Customer.io both ship SSO on Business without a separate enterprise gate.
When a vendor lists SSO only under "Contact sales for Enterprise pricing", you are looking at a manual deprovisioning workflow for every employee transition, for as long as that tool is in the stack.
IdP landscape and compatibility#
Six IdPs dominate enterprise IT:
Okta is the most common cloud IdP in US enterprise. Okta ships SAML 2.0, OIDC, and a polished SCIM interface. A vendor listed in the Okta Integration Network with SCIM confirmed means the IT team's configuration is documented and tested; otherwise they are writing a custom integration.
Microsoft Entra ID (formerly Azure AD) is the default for Microsoft 365 shops. Its SCIM provisioning agent polls the application endpoint — the default interval is 40 minutes, so deprovisioning is not instantaneous. Worth surfacing in the procurement review.
JumpCloud supports SAML 2.0, OIDC, and SCIM 2.0. Popular with mid-market teams that want a cloud directory without on-premises AD.
Google Workspace uses OIDC natively; SAML 2.0 is available for legacy app compatibility. Third-party SCIM integrations follow the standard RFC 7644 path.
OneLogin maintains SAML 2.0, OIDC, and SCIM. Common in mid-market organizations that standardized before Okta's consolidation of the market.
WorkOS is a vendor-side platform (not an end-user IdP) that SaaS applications use to implement SSO and SCIM. A vendor that says "we use WorkOS" is expressing compatibility with Okta, Entra, JumpCloud, Google, and OneLogin simultaneously. Elido's SSO integration is built on WorkOS. The practical implication for IT: if you can point Okta or Entra at a SCIM endpoint, the integration works without vendor-specific configuration work.
JIT provisioning vs SCIM provisioning#
Just-in-Time provisioning creates a user account the first time the user authenticates via SSO. No pre-provisioning step is required; attributes come from the SAML assertion or OIDC token.
JIT solves the provisioning half cleanly. The deprovisioning half is the problem. When the user is removed from the IdP, their SSO session stops working — but the account in the SaaS application persists. Long-lived API tokens may still function. The account appears in any audit of active users.
For ISO 27001 or SOC 2 environments, JIT alone is insufficient. The audit question is not "can this employee log in?" but "is there an auditable record that access was terminated?". JIT doesn't generate that record. SCIM does: the DELETE or { "active": false } event is logged at both the IdP and the SP, timestamped, and queryable.
If your vendor review requires deprovisioning evidence, ask specifically whether SCIM 2.0 deprovisioning is supported. A vendor that answers "yes, we support SSO" when the question was about SCIM is answering a different question.
Role mapping: IdP group to SaaS role#
The standard pattern: the IdP has two groups — marketing-team (all staff) and marketing-leads (team leads). The SaaS application has two roles: Marketer and Admin. The IT team configures the mapping once: marketing-team → Marketer, marketing-leads → Admin. When someone moves between groups, the next SCIM sync updates their role automatically.
SCIM carries group membership via the Groups resource (GET /Groups, POST /Groups, PATCH /Groups/:id). Not all SCIM implementations support group sync — some vendors implement user provisioning only, meaning role mapping still requires per-user manual configuration. Ask the vendor specifically whether SCIM group push is supported and whether the role mapping is admin-configurable without a support ticket.
For EU-based organizations, the IdP group membership data flowing through SCIM may itself constitute personal data under GDPR Article 4(1). The EU data residency for marketing post covers what your DPA should say about the identity data layer. Your SaaS vendor is a processor for that data, and the DPA should address it explicitly.
What to ask in procurement#
Five questions that determine whether a marketing tool's SSO/SCIM integration is a half-day of IT configuration or a multi-week project:
SAML metadata URL. Can the vendor supply a static URL pointing to their SP metadata (entity ID, ACS URL, signing certificate)? This is what you paste into Okta or Entra. Manual metadata entry per customer is a red flag.
SCIM endpoint and auth method. What is the SCIM base URL? Bearer token is the standard; OAuth 2.0 client credentials is more complex. What is the token rotation cadence? A static token that never rotates is a liability.
Deprovisioning latency. When the IdP sends PATCH /Users/:id { "active": false } or DELETE, how quickly is access terminated? Entra's provisioning interval defaults to 40 minutes on the IdP side. The vendor should commit to a processing window once the request arrives. The combination of both latencies is what your SOC 2 auditor will ask about.
Group push support. SCIM group push is separate from SCIM user provisioning. If the vendor only implements user sync, role mapping requires manual per-user configuration. Ask specifically.
IdP tile support. Can the application be added as a tile in the Okta or Entra dashboard and support IdP-initiated login?
The compliance overlay#
ISO 27001 Annex A control A.9.2 requires that user access rights are granted, reviewed, and terminated according to a documented process. A.9.3 requires that users authenticate only with credentials assigned to them. SCIM is the operational mechanism that connects "HR offboarding" to "SaaS access revoked" without manual steps.
SOC 2 CC6.2 requires that entities register and authorize users before granting access. CC6.3 requires periodic access review and removal. The SCIM deprovisioning log — a timestamped record of when the IdP instructed the SaaS application to deactivate or delete a user — is the audit artefact that demonstrates CC6.3 compliance for each application in scope.
Elido is ISO 27001 certified. SOC 2 Type II is in progress, target H2 2026. The identity posture — SAML/OIDC via WorkOS, SCIM 2.0 deprovisioning, group-based role mapping — is documented at the trust page and the solutions/enterprise brief. BAAs are available on the Business plan for HIPAA-adjacent workflows.
The GDPR for URL shorteners cornerstone covers Article 28 and Article 32 in full. SSO and SCIM are the Article 32 technical controls — authentication via SSO, deprovisioning via SCIM — not standalone features. They are components of the security posture your DPO evaluates during the Article 32 review.
/pricing shows the plan breakdown and where SSO/SCIM appear. /solutions/compliance is the buying-team-facing summary. The deprovisioning-evidence conversation belongs in the same procurement call as the DPA, the sub-processor list, and the data residency commitment — those are the questions that determine whether a marketing tool passes the security review.
NIST SP 800-63-3 Digital Identity Guidelines, accessed 2026-05-12, is the authoritative framework for assurance levels and authenticator types that underpins many enterprise IdP policy requirements. The federation section — 800-63C — is directly relevant to SAML and OIDC integration configuration.