What Is Single Sign-On (SSO) and How It Works
One login, everywhere access. SSO eliminates password fatigue and strengthens security by centralizing authentication. Here's how it actually works under the hood, why organizations adopt it, and what to consider before implementation.
the average number of passwords managed by each employee in 2024 - a 67% increase from 2020
How many passwords did you enter today? If you are like most knowledge workers, you probably cannot even remember. Email, Slack, Salesforce, Jira, the HR portal, the expense system, the VPN, the corporate wiki - each one demanding credentials, each one with different password policies, each one another opportunity for a security incident.
The average enterprise user now manages 191 passwords across various systems. Password fatigue is not just an annoyance - it is a security crisis. Users respond rationally to impossible expectations: they reuse passwords, write them down, choose weak ones, and resist rotating them. Every password is an attack surface.
Single Sign-On addresses this problem at the architectural level. Instead of distributing authentication across dozens of applications, SSO centralizes it. Users authenticate once against a single Identity Provider, and that authentication is accepted by all connected applications.
How SSO Works: The Core Concept
Single Sign-On is an authentication scheme that allows users to log in once and gain access to multiple independent applications without re-authenticating for each one.
| Traditional Authentication | SSO Authentication |
|---|---|
| Each app has its own user database | Single user directory |
| Users enter credentials per application | One login for all applications |
| Password policies vary by app | Consistent policy enforcement |
| Password resets handled per app | Centralized self-service |
| Audit logs scattered across systems | Unified authentication logs |
The SSO Transaction Flow
The technical mechanics of SSO depend on which protocol is in use, but the conceptual flow remains consistent across implementations.
The Three Players
| Actor | Role | Example |
|---|---|---|
| User | Person requesting access | Employee |
| Service Provider (SP) | Application being accessed | Salesforce, Slack |
| Identity Provider (IdP) | System that authenticates users | Okta, Azure AD, Ping |
Step-by-Step Flow
SP-Initiated SSO Flow:
- User accesses application - Opens Salesforce, Slack, or any SSO-enabled app
- SP redirects to IdP - Application recognizes user is not authenticated, redirects to Identity Provider
- IdP checks session - Does user have an active IdP session?
- If yes: Skip to step 6
- If no: Continue to step 4
- IdP prompts for login - User enters credentials (username/password + MFA)
- IdP validates credentials - Checks against directory, enforces policies
- IdP creates assertion - Cryptographically signed statement that user is authenticated
- Assertion sent to SP - Via browser redirect or POST
- SP validates assertion - Verifies signature, checks expiry, extracts identity
- SP creates session - User is now logged in to the application
The Protocols That Make SSO Possible
SSO is a concept. SAML, OAuth, and OIDC are the protocols that implement it. Understanding which protocol to use depends on your use case.
Protocol Comparison
| Protocol | Age | Format | Best For |
|---|---|---|---|
| SAML 2.0 | 2005 | XML | Enterprise web apps |
| OAuth 2.0 | 2012 | JSON | API authorization |
| OpenID Connect | 2014 | JSON | Modern web/mobile apps |
SAML 2.0: The Enterprise Standard
SAML uses XML-based messages exchanged through browser redirects:
| Component | Purpose |
|---|---|
| Assertion | XML document containing authentication statement |
| SP Metadata | SP's configuration (endpoints, certificates) |
| IdP Metadata | IdP's configuration (endpoints, certificates) |
| Bindings | How messages are transmitted (POST, Redirect) |
OAuth 2.0: Authorization (Not Authentication)
OAuth provides scoped access tokens for API authorization without sharing passwords.
OpenID Connect: Modern Authentication
OIDC adds identity layer on top of OAuth 2.0, providing true authentication:
| Component | Purpose |
|---|---|
| ID Token | JWT containing user identity claims |
| UserInfo Endpoint | API for additional user attributes |
| Standard Scopes | openid, profile, email, etc. |
Security Implications of SSO
SSO changes the security equation fundamentally. Understanding these implications is critical for implementation decisions.
Security Benefits
reduction in password-related helpdesk tickets after SSO implementation according to Okta research
| Benefit | Why It Matters |
|---|---|
| Password reduction | Fewer passwords means fewer to steal, reuse, or forget |
| Centralized MFA | Enforce strong authentication once, applies everywhere |
| Consistent policies | Password complexity, rotation, conditional access in one place |
| Unified audit logging | Single place to monitor all authentication events |
| Faster deprovisioning | Disable one account, revoke access everywhere instantly |
Security Concerns
| Risk | Mitigation |
|---|---|
| IdP compromise | Phishing-resistant MFA, privileged access management |
| Session hijacking | Short token lifetimes, device binding |
| Assertion forgery | Strong cryptographic validation, certificate management |
| Lateral movement | Conditional access policies, continuous verification |
The MFA Non-Negotiable
| MFA Method | Strength | User Experience |
|---|---|---|
| SMS codes | Weak (SIM swapping) | Familiar |
| TOTP apps | Good | Minor friction |
| Push notifications | Good | Excellent |
| Hardware keys (FIDO2) | Excellent | Learning curve |
| Passkeys | Excellent | Seamless |
SSO Implementation Patterns
How you implement SSO depends on your existing infrastructure, applications, and organizational requirements.
Identity Provider Options
| Type | Examples | Best For |
|---|---|---|
| Cloud IdP | Okta, Azure AD, Ping Identity | Modern cloud-first orgs |
| On-premises IdP | ADFS, Ping Federate | Regulated industries, legacy integration |
| Hybrid | Azure AD Connect | Transitioning organizations |
| Social IdP | Google, GitHub, Facebook | B2C applications |
Application Integration Patterns
| Pattern | Complexity | Use Case |
|---|---|---|
| Pre-built connector | Low | Major SaaS apps (Salesforce, Slack) |
| SAML configuration | Medium | Enterprise apps with SAML support |
| OIDC/OAuth integration | Medium | Modern apps, custom development |
| Header-based | Medium | Legacy apps via reverse proxy |
| Agent-based | High | Apps without native SSO support |
The Just-in-Time Provisioning Question
| Approach | Pros | Cons |
|---|---|---|
| JIT Provisioning | Simple, no sync needed | Accounts created only on first login |
| SCIM Provisioning | Full lifecycle management | More complex setup |
| Manual | Full control | Does not scale, error-prone |
Enterprise SSO Architecture
Large organizations face unique challenges that require careful architectural decisions.
Multi-Directory Environments
Most enterprises do not have a single clean user directory. They have Active Directory domains from acquisitions, cloud directories from SaaS adoption, and legacy systems that predate any standardization.
| Scenario | Solution |
|---|---|
| Multiple AD forests | Azure AD Connect with multi-forest sync |
| AD + Cloud directories | Directory federation, identity governance |
| Legacy directories | Identity virtualization, connectors |
| Partner identities | B2B federation, guest accounts |
Conditional Access: Context-Aware Security
Modern SSO is not just about authentication - it is about authorization context:
| Condition | Example Policy |
|---|---|
| Device state | Block non-compliant devices from sensitive apps |
| Location | Require MFA for logins from new locations |
| Risk score | Step-up authentication for high-risk sign-ins |
| Application sensitivity | Stricter requirements for HR and finance apps |
| Time-based | Block after-hours access to critical systems |
Session Management
| Setting | Consideration |
|---|---|
| Session timeout | Balance security (short) vs user experience (long) |
| Idle timeout | Separate from absolute timeout |
| Single logout | Should logging out of IdP log out of all SPs? |
| Re-authentication | When to require fresh credentials vs cached session |
Common SSO Implementation Mistakes
SSO projects fail for predictable reasons. Understanding these pitfalls helps avoid them.
Pitfall 1: Skipping the Application Inventory
| Discovery Method | What It Finds |
|---|---|
| CASB integration | Cloud apps via network traffic |
| Expense reports | SaaS subscriptions by payment |
| DNS logs | Domains being accessed |
| User surveys | Known applications by department |
Pitfall 2: Underestimating Legacy Applications
Not every application supports modern SSO protocols. Legacy systems may require:
| Challenge | Solution |
|---|---|
| No SSO support | Reverse proxy with header injection |
| LDAP-only auth | IdP with LDAP interface |
| Local accounts only | Password vaulting integration |
| Custom authentication | Agent-based SSO gateway |
Pitfall 3: Ignoring Deprovisioning
Pitfall 4: Poor Emergency Access Planning
| Scenario | Contingency |
|---|---|
| IdP outage | Break-glass accounts for critical apps |
| MFA device lost | Recovery codes, helpdesk bypass procedures |
| Admin lockout | Separate emergency admin accounts |
| Certificate expiry | Monitoring and automated renewal |
SSO vs Related Technologies
SSO is often confused with related but distinct concepts. Understanding the differences prevents miscommunication and implementation errors.
SSO vs Password Manager
| Feature | SSO | Password Manager |
|---|---|---|
| Authentication method | Delegated to IdP | Stores actual passwords |
| Per-app credentials | Eliminated | Still exist, just stored |
| Requires app support | Yes (SAML, OIDC) | No |
| MFA enforcement | Central | Per-app or vault level |
| Enterprise control | Full | Varies |
SSO vs Federation
| Concept | Scope | Purpose |
|---|---|---|
| SSO | Within organization | One login for multiple apps |
| Federation | Across organizations | Trust between different identity systems |
Federation enables SSO across organizational boundaries. Your employees use their corporate identity to access partner systems. Their identity stays in your directory; trust relationships enable cross-organizational authentication.
SSO vs Identity Governance
| Concern | SSO | Identity Governance |
|---|---|---|
| Authentication | Core function | Not addressed |
| Authorization | Basic (group membership) | Detailed entitlements |
| Certification | Not addressed | Access reviews |
| Lifecycle | Basic provisioning | Full joiner/mover/leaver |
| Compliance | Audit logs | Policy enforcement |
SSO Provider Selection
Choosing an Identity Provider is a long-term commitment. Migration is painful and expensive. Choose carefully.
Market Leaders (2025)
| Provider | Strength | Consideration |
|---|---|---|
| Microsoft Entra ID | Microsoft ecosystem integration | Complexity for non-MS shops |
| Okta | Application breadth, usability | Premium pricing |
| Ping Identity | Enterprise features, hybrid support | Implementation complexity |
| Google Workspace | Google-centric organizations | Limited enterprise features |
| OneLogin | Mid-market value | Acquired by One Identity |
| Auth0 | Developer experience | Now part of Okta |
Selection Criteria
| Category | Questions to Ask |
|---|---|
| Integration | Pre-built connectors for your apps? SCIM support? |
| Security | MFA options? Conditional access? Threat detection? |
| Compliance | Certifications? Audit capabilities? Data residency? |
| Scalability | User limits? Performance at scale? |
| Support | SLA? Response times? Professional services? |
| Pricing | Per-user? Per-app? Feature tiers? |
Total Cost Considerations
| Cost Category | Range |
|---|---|
| Per-user licensing | $2-12/user/month |
| Implementation | $50K-500K |
| Annual administration | 0.5-2 FTE |
| Advanced features | Additional licensing |
The Future of SSO
SSO continues evolving as authentication threats change and user expectations increase.
Passwordless Authentication
of security professionals believe passwords will be obsolete within 10 years according to FIDO Alliance research
Passwordless methods eliminate the primary credential that SSO protects:
| Method | Mechanism | Status |
|---|---|---|
| Passkeys | FIDO2 credentials synced across devices | Rapidly adopting |
| Hardware keys | YubiKey, Titan | Enterprise standard |
| Biometrics | Face, fingerprint | Device-dependent |
| Magic links | Email-based temporary tokens | Simple but email-dependent |
Continuous Access Evaluation
Traditional SSO authenticates once per session. Continuous Access Evaluation (CAE) validates authorization throughout the session:
| Traditional | Continuous |
|---|---|
| Check at login | Check continuously |
| Session-based revocation | Near-real-time revocation |
| Static risk assessment | Dynamic risk assessment |
Decentralized Identity
Emerging standards explore user-controlled identity:
| Concept | Promise | Reality |
|---|---|---|
| Self-sovereign identity | User controls own credentials | Limited adoption |
| Verifiable credentials | Cryptographically provable claims | Standards maturing |
| Blockchain identity | Decentralized trust | Mostly hype, some use cases |
SSO Implementation Checklist
A structured approach prevents common failures and ensures security requirements are met.
Phase 1: Discovery and Planning
| Task | Output |
|---|---|
| Application inventory | Complete list of apps needing SSO |
| User population analysis | Groups, roles, access requirements |
| Protocol requirements | SAML vs OIDC per application |
| Security requirements | MFA policy, conditional access needs |
| Timeline and budget | Realistic project plan |
Phase 2: Infrastructure Setup
| Task | Consideration |
|---|---|
| IdP deployment | Cloud, on-prem, or hybrid |
| Directory integration | AD sync, LDAP connections |
| Certificate management | PKI for SAML signing |
| MFA configuration | Enrollment process, backup methods |
| Emergency access | Break-glass procedures |
Phase 3: Application Integration
| Priority | Characteristics |
|---|---|
| High | Many users, pre-built connector, low risk |
| Medium | Department-specific, standard SAML/OIDC |
| Low | Few users, complex integration, legacy |
Phase 4: Testing and Rollout
| Test Type | What to Verify |
|---|---|
| Functional | Login works, attributes pass correctly |
| Security | MFA enforcement, session management |
| Edge cases | Timeout handling, concurrent sessions |
| Failover | IdP outage recovery, break-glass access |
Phase 5: Ongoing Operations
| Activity | Frequency |
|---|---|
| Access reviews | Quarterly |
| Certificate rotation | Before expiry (90+ days notice) |
| Security monitoring | Continuous |
| User feedback collection | Ongoing |
Conclusion: SSO as Foundation
Single Sign-On is not just a convenience feature - it is foundational security infrastructure that enables everything else in modern identity management.
Key Takeaways
The Security Return on Investment
| Before SSO | After SSO |
|---|---|
| Passwords everywhere | Centralized authentication |
| Inconsistent MFA | Universal strong authentication |
| Scattered audit logs | Unified security visibility |
| Slow deprovisioning | Instant access revocation |
| User friction | Seamless experience |
reduction in authentication-related security incidents reported by organizations after comprehensive SSO deployment according to SANS Institute research
Getting Started
For organizations beginning their SSO journey:
- Assess current state - Inventory applications, understand user needs
- Define security requirements - MFA policy, conditional access, compliance needs
- Select IdP - Based on ecosystem, features, and budget
- Start small - Pilot with willing departments and easy applications
- Expand systematically - Add applications based on priority matrix
- Monitor continuously - Authentication logs reveal attack patterns
SSO transforms identity from a per-application problem into an organizational capability. Done right, it improves security while reducing friction. The investment pays dividends across every connected system.
For protocol-specific deep dives, see our companion guides on SAML 2.0, OAuth 2.0, and OpenID Connect.
Frequently Asked Questions
Single Sign-On lets you log in once and access multiple applications without entering credentials again. Instead of having different usernames and passwords for each application, you authenticate to a central Identity Provider, and that authentication is trusted by all connected applications.
SSO improves security by reducing password sprawl (users have one strong password instead of many weak ones), enabling consistent MFA enforcement across all applications, centralizing authentication monitoring and threat detection, and simplifying access revocation when employees leave. The IdP can implement sophisticated security controls that would be impractical to deploy in every individual application.
No. Password managers store and auto-fill multiple passwords - you still have separate credentials for each application. SSO uses federated authentication so applications don't have passwords at all; they trust the Identity Provider's assertion of your identity. Password managers help users cope with password sprawl; SSO eliminates password sprawl.
Federation is the trust relationship between an Identity Provider and applications that accept its assertions. SSO is the user experience that federation enables. Federation is the mechanism; SSO is the result. In practice, the terms are often used interchangeably.
If the Identity Provider becomes unavailable, users cannot authenticate to SSO-enabled applications. This is why IdP availability is critical - choose IdPs with strong uptime SLAs, consider redundancy options, and maintain break-glass access procedures for critical applications.
Yes, modern SSO protocols (especially OIDC) work well with mobile applications. The authentication flow redirects users to the IdP's mobile-optimized login page or uses native authentication features. SAML-based SSO can work with mobile apps but often provides a less smooth experience.
SSO handles authentication (proving who you are), not authorization (what you can do). After SSO verifies your identity, each application still makes its own authorization decisions based on roles, groups, or permissions assigned within that application. Some IdPs pass group membership or role information to applications, but the application determines what those roles mean.
Yes, through workarounds. Enterprise SSO solutions offer password vaulting for legacy applications (storing and auto-filling credentials), reverse proxy authentication for applications that support header-based auth, and custom adapters for specific scenarios. These approaches provide SSO-like user experience for applications without native federation support.
SAML 2.0 and OpenID Connect (OIDC) are the dominant protocols. SAML is prevalent in enterprise environments and legacy SaaS applications. OIDC is growing rapidly, especially for modern applications and consumer SSO ('Sign in with Google'). Most Identity Providers support both protocols.
Implementation timeline depends on scope. Enabling SSO for a single cloud application with good IdP integration takes hours to days. Rolling out SSO across an enterprise with dozens of applications, legacy systems, and custom integrations takes months. Start with a pilot of high-value applications, gain experience, then expand systematically.
Comments
Want to join the discussion?
Create an account to unlock exclusive member content, save your favorite articles, and join our community of IT professionals.
New here? Create a free account to get started.