Single sign-on is one of those features that does not matter at all until it becomes a dealbreaker. Your security team asks for it, procurement may demand it, and compliance reviewers often expect a clear access-control story. Yet many teams underestimate the planning required, pick the wrong protocol for their environment, or discover mid-project that what worked for one identity provider does not work for the next.
Why SSO keeps stalling enterprise deals
SSO is commonly treated as a security expectation, a compliance support control, and a procurement condition. When a prospect's IT team asks whether you support their identity provider and the answer is no, the deal stalls. Enterprise buyers treat SSO as mandatory infrastructure.
The challenge is that SSO implementation is not a weekend project. It involves protocol decisions, certificate management, session alignment, provisioning logistics, and testing against real identity providers that each behave differently. An enterprise SSO rollout can require meaningful engineering coordination, and the first integration often shapes choices that affect later integrations.
For compliance teams specifically, SSO matters beyond just login convenience. Centralised authentication helps enforce consistent access policies, maintain audit trails, and support identity-management expectations. Many assurance programs ask organisations to demonstrate that access is controlled, auditable, and revocable. SSO is the technical foundation for all three. If you are evaluating compliance tooling, SSO support is one of the first things to verify.
Protocol selection: SAML vs OIDC
Two widely used enterprise SSO protocols are SAML 2.0 and OpenID Connect (OIDC). Both accomplish the same goal of federated authentication, but they work differently and serve different audiences.
SAML 2.0
SAML is the older protocol, XML-based, and deeply entrenched in enterprise IT. If your customers use enterprise identity providers, they almost certainly support SAML. The protocol exchanges XML assertions between the identity provider (IdP) and your application (the service provider). It is battle-tested, widely supported, and frustrating to debug because of the XML parsing, certificate management, and redirect flows involved.
Choose SAML when:
- Your service providers are enterprise SaaS apps that overwhelmingly support SAML
- You need fine-grained attribute statements like department, cost centre, or entitlements
- Your identity provider is an on-premises system that only speaks SAML
- Your customers require IdP-initiated SSO from their portal
OpenID Connect
OIDC is built on top of OAuth 2.0 and uses JSON instead of XML. It is simpler to implement, easier to debug, and increasingly supported by enterprise identity providers. Many identity providers support both SAML and OIDC, while some enterprise environments still require SAML.
Choose OIDC when:
- Your service providers are modern web or mobile applications
- You need lightweight token-based authentication for single-page applications or APIs
- You want simpler integration with less configuration overhead
- You are building something new with no legacy constraints
The honest recommendation
Support both. Start with OIDC because it is often simpler to implement and maintain, then add SAML for customers whose identity providers require it. In practice, many enterprise SSO requests can be handled with OIDC, while some customer environments still need SAML. If you are building a product targeting enterprise, plan for both from the beginning.
| Dimension | SAML 2.0 | OpenID Connect |
|---|---|---|
| Token format | Signed XML assertions | Signed JWT ID tokens |
| Transport | Browser POST/Redirect bindings | OAuth 2.0 back-channel + redirects |
| Setup complexity | Manual metadata exchange per IdP | Discovery endpoints reduce hand-wiring |
| Mobile / SPA support | Awkward, requires workarounds | Native, designed for these clients |
| Enterprise adoption | Widely established, entrenched | Growing rapidly, becoming default |
| IdP-initiated flow | First-class support | Not standardised, treated as anti-pattern |
| Common fit for | Legacy enterprise, government, regulated industries | Modern web, mobile, API-first, SPAs |
The implementation path
Step 1: Abstract your authentication layer
Consolidate authentication logic behind a single service. If auth code is scattered across files, unify login, logout, session creation, and user lookup so SSO plugs in as another source without touching core auth logic.
This step pays for itself immediately. Without it, every SSO integration becomes a bespoke project that touches authentication code in unpredictable places.
Step 2: Build the manyant configuration interface
Create an admin interface where organisation administrators can input their identity provider details. For SAML, this means uploading IdP metadata XML or entering the entity ID, SSO URL, and certificate manually. For OIDC, this means entering the discovery URL (or issuer), client ID, and client secret. Validate the configuration before saving.
Store identity provider configuration per manyant in a database, not in config files or environment variables. When you have more than a handful of enterprise customers, hardcoded configuration becomes a deployment bottleneck. Every certificate rotation, every identity provider migration, every new customer becomes a code change rather than a configuration update.
Step 3: Implement the authentication flow
For SAML, this involves generating AuthnRequest objects, redirecting to the identity provider, consuming the SAML Response, validating the XML signature, and extracting the user attributes. For OIDC, this involves redirecting to the authorization endpoint, handling the callback, exchanging the code for tokens, and validating the ID token.
Libraries handle the heavy lifting, but you still need to understand the flow to debug issues. A recurring implementation mistake is treating SSO as authentication-only and skipping provisioning logic, which creates a gap where users authenticate successfully but have no application account.
Step 4: Handle user mapping
The identity provider returns an identifier for the user, usually an email address or a unique ID. Your application needs to map this to an existing user account or create a new one. Edge cases here include users who already have a password-based account, email addresses that do not match the expected domain, and identity providers that send different attributes than expected.
Do not use email as the primary identity key. Email addresses change. When a user updates their email in the identity provider and your system looks them up by email, you get duplicate accounts. Use an immutable, provider-specific identifier instead, and treat email as profile data.
Step 5: Test with real identity providers
This is where implementations often break. Testing with a mock identity provider is necessary during development, but the real test is connecting to actual enterprise identity providers with real configurations. Each identity provider has quirks. Some send group claims differently than others. Some have specific requirements around relay state. Budget time for identity provider-specific debugging.
Test both SP-initiated and IdP-initiated flows. Many implementations only handle SP-initiated flow (user visits your app, gets redirected to the identity provider, comes back). IdP-initiated flow (user clicks your app from their identity provider portal) requires different validation logic because there is no prior request to validate against. If you skip this, customers who launch your app from their portal will get errors.
Failure modes that create avoidable rework
Certificate rotation
SAML uses X.509 certificates to sign assertions, and these expire. Without support for multiple active certificates, customers face authentication failures when their identity provider rotates. Support overlapping active certificates per manyant.
Clock skew
SAML assertions contain timestamps with tight validity windows. If your server clock drifts by even a few minutes, assertions get rejected intermitmanytly. The problem is not reproducible in your environment because it depends on the customer's infrastructure. Configure NTP on all authentication servers and add a configurable clock skew tolerance of a small tolerance window. Do not exceed a broad tolerance window or you defeat the purpose of the time constraint.
Session lifetime mismatch
SSO introduces at least several separate session clocks that many teams overlook: the identity provider session (how long the IdP considers the user authenticated), the browser session (cookie-based), and each application session (set independently). When these three clocks are not aligned, the shortest one wins. Users experience unpredictable logouts with no obvious cause.
Align session lifetimes deliberately. A common starting configuration is an identity provider session of a business-day session with a sliding window, application sessions of a shorter session, and silent re-authentication enabled for OIDC applications.
Single logout fragility
Single logout sounds appealing but is structurally unreliable at scale. Front-channel single logout depends on a browser redirect chain reaching every participating provider, and a single unreachable endpoint breaks the chain. Back-channel logout is more reliable in principle but only works if every relying party actually implemented the logout endpoint correctly.
In practice, keep session lifetimes short enough that a missed logout call has a bounded window of exposure. Maintain a centralised session store the identity provider can use to force-revoke sessions independent of whether logout fired. Do not depend on single logout as your primary session termination mechanism.
Error handling and support burden
SSO failures are opaque to end users. "Authentication failed" tells them nothing. Log the full SAML response or OIDC error, including the specific validation failure, so your support team can diagnose issues. Surface a meaningful error to the user when possible, such as "Your organisation's SSO certificate has expired, please contact your IT administrator."
SSO support tickets often come from the same handful of causes: email used as the primary identifier, missing just-in-time provisioning, no IdP-initiated flow support, and per-tenant identity provider configuration stored as application config rather than database records.
Provisioning: JIT vs SCIM
SSO solves authentication. Provisioning solves account lifecycle. Many teams start with just-in-time (JIT) provisioning, which creates an account on first successful SSO login using attributes from the assertion.
SCIM provisioning goes further by letting the identity provider push user creates, updates, and deprovisioning events to your application proactively. Enterprise customers with strict offboarding expectations may eventually ask for SCIM. It is often useful when you need to demonstrate that access is revoked when employment ends.
| Approach | What it does | When it breaks |
|---|---|---|
| JIT provisioning | Creates account on first SSO login | Cannot deprovision; stale accounts persist |
| SCIM provisioning | Push lifecycle events from IdP | Requires IdP support; more complex setup |
| Both | JIT for fast start, SCIM for lifecycle | More integration surface, but covers all cases |
SSO and compliance frameworks
For compliance teams evaluating SSO, the protocol choice matters less than the operational discipline around it. Many assurance programs look for consistent access control, audit trails, and timely revocation.
What auditors actually look for:
- Centralised authentication with enforced MFA
- Audit logs that trace each material access decision
- Timely deprovisioning when users leave the organisation
- Session management that balances security with usability
- Evidence that identity provider configuration is reviewed regularly
SSO gives you the technical foundation, but the compliance value comes from how you operate it. Short session lifetimes, automated provisioning and deprovisioning, and regular access reviews turn SSO from a login convenience into an auditable control.
Getting SSO right without over-engineering it
Strong SSO implementations share a few traits:
Start with OIDC for new builds. It is faster to implement, easier to debug, and the default for modern applications. Add SAML when a customer requires it, not before.
Plan for both protocols from the start. Even if you start with OIDC, design your authentication abstraction layer so adding SAML later does not require rewriting core auth logic.
Test against real identity providers early. Mock identity providers catch structural issues but not the quirks that break real integrations. Connect to more than one identity provider during development.
Treat provisioning as part of SSO, not a separate project. JIT provisioning on day one, SCIM before you go upmarket to enterprise buyers with strict offboarding requirements.
Price SSO appropriately. It requires ongoing maintenance, customer support for identity provider configuration, and testing against multiple identity providers. It is a premium feature that unlocks enterprise value.
How CASK fits into the identity picture
CASK fits into your identity picture without becoming another cloud dependency. It is a local-first, desktop-native workspace where agents prepare compliance artifacts grounded in your documents. SSO handles who can access CASK. CASK handles what happens with your data inside.
CASK's architecture means authentication and data storage are separate concerns. Your identity provider handles who can access CASK. CASK handles what happens with your compliance data once you are inside. The two layers work together without forcing your sensitive compliance documents through a cloud-hosted identity provider.
For teams evaluating compliance tooling alongside their SSO requirements, CASK's local-first approach means one fewer cloud service to federate with, one fewer data residency concern, and one fewer vendor whose availability depends on an identity provider integration. When comparing GRC tool pricing and total cost of ownership, factor in the operational overhead of SSO integrations across your vendor stack.
Related Reading
For related context, see identity governance practices, evaluating compliance tooling, local-first approach, and comparing GRC tool pricing and total cost of ownership.
FAQ
What is the difference between SAML and OIDC for SSO implementation? SAML uses signed XML assertions exchanged through browser redirects. OIDC uses signed JSON tokens built on OAuth 2.0. SAML is the enterprise standard with deep adoption in government and regulated industries. OIDC is simpler to implement and fits modern web, mobile, and API-first applications. Many organisations support both.
How long does a typical SSO implementation take? A typical enterprise SSO project can take sustained effort from protocol selection to production rollout. The first identity provider integration often takes the most coordination because each decision depends on choices made at the start. Subsequent integrations become easier once the process is established.
Should we support both SAML and OIDC? Yes, if you sell to enterprise. Your customer base will include identity providers that speak one, the other, or both. Supporting both removes the protocol bet and shormanys sales cycles. Start with OIDC for new builds and add SAML before your first enterprise deal.
What happens if our identity provider goes down? If the identity provider is unreachable, new login attempts across all federated applications fail simultaneously. Mitigate this with identity provider redundancy, offline authentication fallbacks for critical systems, and careful availability planning. Existing sessions typically continue until they expire.
Do we need SCIM provisioning alongside SSO? SSO handles authentication. SCIM handles account lifecycle, including deprovisioning. If you need to demonstrate to auditors that access is revoked when users leave, SCIM is usually stronger than JIT provisioning alone because it can deactivate accounts.