Single Sign-On (SSO) Implementation
This article is for educational purposes only and does not constitute professional compliance advice or legal counsel. Requirements and standards evolve, and you should consult with a qualified compliance professional about your specific situation.
Your IT team has been hearing about single sign-on for months. It sounds like a win-win: users get one password instead of managing dozens, and IT teams get centralized access control instead of managing passwords across dozens of systems. Vendors promise rapid deployment. But by month four of your implementation, you're dealing with legacy applications that won't integrate, users locked out because they forgot their SSO credentials, and a project timeline that's stretched from three months to nine. SSO does improve both security and usability, but only if you understand what you're actually implementing and what goes wrong when implementation is rushed or incomplete.
How SSO Works and Federation Fundamentals
Single sign-on solves a real problem. Traditionally, users have accounts in many systems—email, file shares, cloud applications, customer databases, internal tools. Each system manages its own passwords and authentication. Users need to remember different passwords for different systems. IT teams need to manage passwords in multiple places. When someone leaves the company, access needs to be revoked from every system individually.
SSO delegates authentication to a central identity provider that users trust, then that provider vouches for the user to applications. Instead of each application managing passwords, users authenticate once to the central provider, get a token proving authentication, and present that token to applications. The application doesn't need to store passwords anymore or verify authentication directly—it just trusts that the identity provider did the job correctly.
This works because of federation. Federation is the broader concept: allowing users to access resources across organizational boundaries using credentials from their home organization. SSO is federation within a single organization—same principles, different scope. When you implement SSO, you're saying "these applications will trust our central identity provider to verify user identity."
The critical assumption in all of this is that the identity provider is actually trustworthy. If the identity provider is compromised or starts issuing false authentication vouchers, the game is over. Applications trust it, so compromising it compromises everything. Implementation quality determines whether that trust is actually justified. A poorly implemented SSO system where the identity provider issues tokens without verifying credentials is worse than no SSO at all.
SAML vs OpenID Connect: The Protocol Choice
Two main protocols make federation work. SAML—Security Assertion Markup Language—is the older standard, created in the early 2000s, and is what most enterprises implemented for SSO. It uses XML and is relatively verbose. When a user tries to access an application, SAML has a detailed handshake: the application requests authentication, the identity provider verifies the user, issues an assertion, the user presents that assertion back to the application, and the application verifies the assertion with the identity provider. It works but requires multiple round-trips.
OpenID Connect is newer—created in the 2010s—builds on OAuth, uses JSON instead of XML, and is simpler. The flow is more streamlined. For most users the differences are invisible, but for engineers implementing integrations, SAML is more ceremony and configuration, OpenID Connect is more straightforward.
For most organizations, the protocol choice comes down to what your identity provider and applications support rather than which protocol is objectively better. Microsoft Entra—formerly Azure AD—supports both SAML and OpenID Connect. Okta supports both. Google Workspace uses OpenID Connect. Ping Identity supports both. The practical reality is that your tooling ecosystem determines the choice more than technical differences.
The important understanding is that the protocol handles the mechanics of proving authentication and passing that proof to applications. The protocol determines implementation complexity more than it determines security outcomes. Both SAML and OpenID Connect can be implemented securely or poorly. What matters more is what comes next—what happens when users authenticate to the identity provider.
Multi-Factor Authentication with SSO
This is the part that makes or breaks SSO security. When a user authenticates to the SSO provider, what mechanism do they use? If they authenticate with just a password, SSO has made your environment as secure as your weakest password. If they authenticate with multi-factor authentication—password plus something else—then compromising a single user's credential doesn't compromise their account.
Modern identity providers all support MFA. Users can authenticate with password plus a time-based authenticator app, password plus a push notification to their phone, password plus a hardware security key, or various combinations. The implementation gets messy when legacy applications in your environment don't support modern authentication flows. Some organizations allow users to authenticate with MFA to the corporate SSO provider but then have the provider pass only the username to legacy applications, which prompt for a second password. This defeats the entire purpose—you still have multiple passwords and weak authentication at the application layer.
The right implementation is that users authenticate with MFA to the identity provider once, and applications trust that authentication. No additional password prompts at the application layer. No workarounds that undermine the security. Some legacy applications can't support this, and those applications probably shouldn't be in scope for SSO—leaving them out of SSO with separate authentication is more honest than implementing SSO in a way that's theater.
Proper SSO implementation means strong primary authentication. The typical implementation is password plus a push notification to a phone or password plus a time-based authenticator app. Both achieve the security goal: someone would need to compromise multiple different attack vectors to gain access. Hardware security keys are more secure but users resist carrying additional devices. SMS-based codes are better than nothing but weaker than app-based or hardware-based.
Session Management and Token Handling
Once a user authenticates to the identity provider, the provider issues tokens proving authentication happened. These tokens have expiration times—they shouldn't last forever. A short-lived access token valid for 15 minutes or an hour is safer than a token valid for 24 hours because the window of exposure if someone steals the token is shorter.
Refresh tokens allow users to get new access tokens without re-authenticating, but refresh tokens should themselves be short-lived or require more protection. The flow is typically: user authenticates, gets an access token good for 1 hour and a refresh token good for 24 hours. When the access token expires, the application uses the refresh token to get a new access token without the user entering credentials again. If the refresh token expires too, the user re-authenticates and gets new tokens. This balances security and usability.
The complexity here is that tokens can be stolen in transit or from devices. If network traffic isn't encrypted or if someone's device is compromised, tokens can be captured. Someone who steals an access token has temporary access until it expires. Someone who steals a refresh token might have longer access. The standard answer is to always encrypt traffic between clients and servers and to protect tokens in storage, but in practice this isn't uniformly done.
Token revocation—invalidating a token before it expires—is theoretically important but hard to implement at scale. If you revoke a token that might be held by thousands of users' devices, you need real-time communication with all those devices to tell them the token is invalid. This is expensive and complex. Most implementations don't actually revoke tokens; they just let them expire. This is a known security limitation that organizations accept because implementing true revocation is harder than the risk usually justifies.
Application Integration and Compatibility
Not every application in your environment can participate in SSO. Legacy applications were built decades ago before federation protocols existed. Custom applications might not support SAML or OpenID Connect. SaaS applications have varying support—some have native support, others have it only in premium tiers, others don't have it at all.
Integration effort is consistently underestimated in SSO projects. Each application is a unique integration challenge. A cloud application with native SAML support might integrate in a day or two. An older SaaS application might require a custom connector that takes weeks. An on-premises legacy application might not support modern authentication at all and might need to stay on separate authentication. Some applications need "reverse proxy" solutions that sit in front of the legacy system and handle authentication, adding complexity and another system to maintain.
The discovery phase of SSO projects often reveals how messy the application landscape is. You probably have more applications than you think—that tool the finance team uses, the custom system engineering built internally, the vendor-managed system you don't directly control. Not all of them will integrate cleanly with SSO. Some integration projects drag on because the vendor is slow to respond or the integration documentation is poor. This is where SSO project timelines blow up and where scope negotiations get real.
The practical implication is that you need to inventory your applications and understand which ones will participate in SSO and which ones won't. Applications with native SSO support integrate faster. Applications that require custom connectors take longer. Applications that don't support SSO at all stay on separate authentication or might need to be replaced.
Deployment Scope and Phased Rollout
You cannot flip a switch and require SSO everywhere on day one. Different organizations take different approaches to phasing SSO. Some start with SaaS applications that have native support—tools like Salesforce, Slack, Zoom, and Jira integrate with SSO relatively easily. Then they move to on-premises applications. Then they tackle custom applications that are harder to integrate. Some start with a pilot group of early adopters, confirm the system works, then expand to the broader organization. Some require SSO for all new hires and gradually migrate existing users.
The phasing strategy matters for adoption and success. If you force migration before the identity provider is stable, users get frustrated. If you force migration before all applications are integrated, users get locked out. If you do this too slowly, you never realize the benefits of centralized management because you're still maintaining separate authentication systems in parallel.
The typical progression is something like: months 1-3 focus on identity provider deployment, testing, and hardening the authentication layer with MFA. Months 3-6 focus on integrating the easiest applications. Months 6-9 focus on integrating harder applications and addressing integration challenges. Months 9-12 involve phased user migration, starting with early adopters who can tolerate problems, then expanding to broader user groups. Parallel maintenance of legacy authentication continues through this entire period because you're not ripping out old systems until you're confident the new system works.
The transition from planning to pilot to production is critical. A pilot with 50 early adopters and real IT support might work smoothly, but rolling out to 500 users encounters problems the pilot didn't surface. Scalability issues, support bottlenecks, integration gaps that didn't matter in pilot suddenly matter when they affect many users. Good organizations phase slowly and stay ready to pause rollout if problems emerge.
Closing Beat
You now understand that SSO is about centralizing authentication so users authenticate once and applications trust that authentication, that proper implementation requires strong primary authentication like MFA, that token management has real security implications you need to understand, and that integration effort is usually the real project challenge, not the identity provider deployment.
When you're planning SSO, resist the vendor pitch that makes it sound like a two-month project. Focus on which applications need to participate, how hard each integration actually will be, what the realistic migration path looks like, and whether you have the technical resources to handle integrations. Plan to phase gradually and stay ready to slow down if problems emerge. The security benefits of SSO are real but only if implementation is done carefully and applications are properly integrated.
Fully Compliance provides educational content about IT compliance and cybersecurity. This article reflects general information about SSO implementation as of its publication date. Standards and best practices evolve — consult a qualified compliance professional for guidance specific to your organization.