Single Sign-On Implementation: What Actually Goes Wrong

SSO projects fail on provisioning, group mapping, and lockout scenarios rather than on protocol implementation. The protocol is the documented part. This guide covers the rest, drawing on FISTA Solutions' web and mobile work.

What decides the project?

Operational questions rather than protocol details.

Question	Why it decides
How are accounts created?	Manual provisioning does not scale
How are they removed?	Security-critical and often missed
How do groups map to roles?	Where the per-customer work sits
What if the provider is down?	Lockout risk for everyone
How long is a session?	Interacts with directory changes
Who tests it?	Real directories differ from samples

Which protocol, and does it matter?

OpenID Connect for new integrations, SAML where enterprise customers require it, and frequently both.

The protocol rarely determines success. Both are well specified, well supported by libraries, and understood by identity providers. Implementing them correctly is a solved problem with good tooling.

Supporting SAML is usually a commercial requirement rather than a technical preference. Enterprise buyers ask for it, and the answer affects deals more than it affects architecture.

How should provisioning work?

Automatically, through a provisioning protocol or just-in-time creation on first login, with updates flowing from the directory.

Just-in-time creation is simpler and handles the common case: a user authenticates, an account is created with attributes from the assertion. It does not handle removal, which is the half that matters for security.

Automated provisioning handles both and requires more integration work. For enterprise customers it is frequently expected rather than optional.

Why is deprovisioning the critical half?

Because a user removed from the directory who retains access to your system is exactly what SSO was meant to prevent.

Just-in-time provisioning alone leaves those accounts active. The user cannot log in through the provider, and any local credential, API key, or long-lived session still works.

Decide what happens on removal: account disabled, sessions invalidated, tokens revoked, API keys deactivated. That list is usually longer than teams expect and it belongs in the design rather than in a later ticket.

What makes group mapping difficult?

Customer directories are organised for their purposes and rarely match your permission model.

The options are configuration per customer — mapping their group names to your roles — or a convention they must follow. The first scales badly with many customers; the second requires them to change their directory, which they will resist.

Most products end up with per-customer configuration and an interface for administrators to manage it. Building that interface is part of the project rather than an addition to it.

What is the break-glass path?

A way in when the identity provider is unavailable, misconfigured, or the integration is broken.

Without it, a provider outage or a configuration mistake locks out everyone including the administrators who could correct it. That failure happens more often than teams expect, usually during a configuration change made with good intentions.

A local administrator account with strong protection, used rarely and monitored, is the usual answer. Decide it before launch rather than during the incident.

How do session lifetimes interact?

Your session lifetime determines how long a user retains access after directory changes.

A long local session means a removed user keeps working until it expires. A short one means frequent redirects to the provider, which is fine when the provider session is live and disruptive when it is not.

The usual arrangement is a moderate local session with re-authentication against the provider, plus immediate invalidation on deprovisioning events. That gives reasonable usability and bounded exposure. See authentication architecture guide.

What are the common mistakes?

Just-in-time provisioning without deprovisioning. No group mapping interface. No break-glass path. Long sessions with no invalidation on removal. And testing only with sample directory data.

How do you test it?

Test with a real customer directory rather than a sample, test deprovisioning end to end, test provider unavailability, and test a misconfigured assertion.

Real directories contain attributes, group structures, and edge cases that sample data does not, and those are where integrations fail on the first customer.

What does it cost to operate?

Modest to implement with a library or an identity platform, larger to operate across many customers because each brings configuration and support load.

Budget support capacity. SSO configuration is where enterprise onboarding stalls, and the questions are usually about the customer's directory rather than about your product.

What should you measure?

Failed authentication rate by customer, time to configure a new customer, deprovisioning latency, and support tickets related to identity configuration.

What about machine identity?

It is a separate problem. SSO handles humans; services, integrations, and agents need their own identities with scoped credentials.

Using a human's SSO session for automated access breaks when they leave and makes actions unattributable. Give non-human callers their own identity from the start. See what is least privilege for AI agents.

When is this the wrong approach?

For a consumer product with individual users and no organisational structure, SSO adds complexity without the administrative benefit it exists to provide. Social or passwordless login serves better there.

What should you do first?

Decide what happens when a user is removed from a customer's directory. That answer determines whether you need full provisioning or whether just-in-time creation is enough.

How FISTA Solutions helps

FISTA Solutions builds and operates production systems through web and mobile, AI enablement, and staff augmentation: provisioning and deprovisioning designed together so access ends when it should, break-glass access agreed before the first configuration change, decisions documented with their reasoning, and handover that leaves your team able to maintain what was delivered. The record is 150+ projects for 50+ companies across 12+ countries.

To scope this work, message FISTA on WhatsApp, or read authentication architecture guide.