Enterprise IT won't approve software that doesn't support SSO.
SAML and OIDC SSO allow enterprise users to log into your application with their company credentials. It's a non-negotiable for procurement at companies with an IT team. Implementing SAML is complex; using a provider like Clerk or WorkOS handles the protocol complexity.
Enterprise prospect blocking on SSO/SAML support — their IT team requires SSO as a condition of deployment
Enterprise SSO uses two protocols:
SAML 2.0: The older, XML-based standard. Still dominant in enterprise environments. Okta, Azure AD, PingFederate, and many others use SAML. Complex XML signature verification; most developers avoid implementing it manually.
OIDC (OpenID Connect): The modern, JSON/JWT-based standard. Okta, Azure AD, Google Workspace, and others support OIDC. Simpler to implement than SAML; increasingly common in newer enterprise environments.
What SSO enables:
- Users log in with their corporate credentials (no separate username/password)
- IT controls access (deactivating a user in Okta automatically removes access)
- IT enforces security policies (MFA required by corporate policy, not by your application)
The implementation options:
Clerk SSO: Clerk Enterprise plan supports SAML and OIDC SSO. Configuration per organization — each enterprise customer adds their identity provider configuration in Clerk's dashboard (or via API). No SAML protocol code to write.
WorkOS: Purpose-built for enterprise auth features. SSO, directory sync (SCIM), and audit logs. Pricing per connection. Higher per-connection cost than Clerk; more enterprise features.
Self-implemented (node-saml):
node-saml library handles the SAML protocol. More control; significantly more implementation complexity. Appropriate only when Clerk/WorkOS pricing doesn't work at scale.
Organization-level configuration:
Each enterprise customer has their own SSO configuration (their IdP's metadata URL). The product needs an admin interface to set up SSO per organization, or a manual onboarding process.
SAML/OIDC SSO implementation that allows enterprise users to authenticate with their company identity provider (Okta, Azure AD, Google Workspace)
Clerk Enterprise SSO
setup (SAML + OIDC)
Per-organization SSO configuration
(admin UI or manual setup)
Just-in-time provisioning
(auto-create user accounts on first SSO login)
SSO enforcement
option (block non-SSO login for enterprise orgs)
SCIM directory sync
(optional — for automatic user provisioning/deprovisioning)
One honest number to start.
Fixed-scope, fixed-price. The number below is the starting point — final scope is built from your brief.
SAML/OIDC SSO implementation that allows enterprise users to authenticate with their company identity provider (Okta, Azure AD, Google Workspace)
Three steps, every time.
The same repeatable engagement on every project. No surprises, no mystery, no billable ambiguity.
Brief & discovery.
We send you questions, then get on a call. Output: a written scope with every step, feature, and integration listed.
Build & ship.
Fixed schedule, weekly reviews. No scope creep unless you change the scope — and if you do, we reprice it transparently.
Warranty & retainer.
30-day warranty on every launch. Most clients stay on a monthly retainer for ongoing features and maintenance.
Why Fixed-Price Matters Here
SSO scope is defined by the implementation choice and the enterprise feature requirements. Fixed-price.
Questions, answered.
With Clerk: 1-2 weeks including testing. SAML self-implemented: 4-8 weeks. The protocol complexity is the variable.
Social login (Google, GitHub) is for individual users using personal accounts. SSO is for employees using their corporate identity. An enterprise customer's IT team controls SSO; individual users control social login.
Tell Ryel about your project.
Describe what you’re building and what outcome you need. You’ll have a written, fixed-price scope within the week.