# Single Sign-On Architecture
Single Sign-On (SSO) is an authentication architecture that allows users to authenticate once with a central identity provider and gain access to multiple applications without re-entering credentials. SSO centralizes identity management while reducing password fatigue and attack surface.
The fundamental problem SSO addresses is credential sprawl. The average enterprise employee has access to 87 different applications. Without SSO, each application requires separate credentials, creating a management nightmare for users and security teams alike. Users resort to password reuse across applications, choose weak passwords they can remember, or store credentials in insecure locations like browser password managers or sticky notes. IT departments face a constant stream of password reset requests and struggle to enforce consistent authentication policies across diverse application portfolios.
SSO exists because identity is the new perimeter. Traditional network security assumed users were inside trusted networks and applications were outside untrusted networks. That model collapsed with cloud adoption, remote work, and mobile access. Modern security architecture assumes no inherent trust and requires verification for every access request. SSO provides the infrastructure to verify identity once and extend that verification across multiple applications through federation protocols.
SSO fits into modern security architecture as foundational identity infrastructure, similar to how DNS provides foundational naming infrastructure for the internet. Just as applications rely on DNS to resolve hostnames to IP addresses, modern applications rely on SSO to resolve user identity to access decisions. SSO enables other security capabilities like conditional access policies, privileged access management, and identity governance. Without SSO as the foundation, these capabilities become fragmented and inconsistently applied across the application portfolio.
SSO implementations use federation protocols to establish trust between Identity Providers (IdPs) and Service Providers (SPs). The three primary protocols are SAML 2.0, OpenID Connect, and legacy systems like WS-Federation.
SAML 2.0 (Security Assertion Markup Language) exchanges XML assertions through browser redirects. When a user accesses a SAML-enabled application, the application redirects the user's browser to the configured IdP with a SAML authentication request. The IdP authenticates the user and constructs a SAML assertion containing identity attributes and authentication context. The assertion is digitally signed by the IdP and sent back to the application through the user's browser. The application validates the signature and extracts user identity from the assertion. SAML works well for enterprise applications because it provides rich attribute exchange and strong security guarantees, but the XML-based approach makes it complex to implement in modern web applications.
OpenID Connect (OIDC) layers identity on top of OAuth 2.0 using JSON Web Tokens (JWT). OAuth 2.0 was designed for authorization, not authentication, but OIDC adds an identity layer that makes it suitable for SSO. When a user accesses an OIDC-enabled application, the application redirects to the IdP authorization endpoint with parameters specifying the requested scopes. After authentication, the IdP returns an authorization code to the application. The application exchanges this code for an access token and an ID token at the IdP token endpoint. The ID token is a JWT containing identity claims about the authenticated user. The application validates the JWT signature and extracts user identity from the claims. OIDC is preferred for modern web and mobile applications because it uses lightweight JSON instead of XML and maps naturally to REST APIs.
The authentication flow follows predictable patterns regardless of protocol. First, the user attempts to access a protected resource at a Service Provider. The SP determines the user is not authenticated and redirects to the appropriate Identity Provider. The IdP presents a login interface and validates the user's credentials through methods like username/password, multi-factor authentication, or risk-based authentication. After successful authentication, the IdP constructs a token or assertion and sends it to the SP. The SP validates the token and extracts user identity and attributes. Finally, the SP grants access to the requested resource based on the authenticated identity and applicable authorization policies.
Session management determines how long SSO sessions persist and when re-authentication is required. IdP sessions track authentication state at the identity provider, while SP sessions track access state at individual applications. Session timeout policies balance security and usability. Short timeouts reduce exposure from stolen sessions but increase authentication friction. Long timeouts improve user experience but extend the window for session-based attacks. Sophisticated implementations use risk-based session management that adjusts timeout based on factors like user location, device trust level, and application sensitivity.
Just-in-Time (JIT) provisioning creates user accounts in applications automatically during the first SSO login. Traditional provisioning requires manual account creation or complex synchronization processes. JIT provisioning reads user attributes from SSO assertions and creates application accounts dynamically. This approach reduces administrative overhead and ensures users have access to new applications immediately after they are granted SSO access. However, JIT provisioning can create orphaned accounts if not paired with automated deprovisioning processes.
SCIM (System for Cross-domain Identity Management) provides standardized APIs for user lifecycle management across applications. While SSO handles authentication, SCIM handles the provisioning and deprovisioning of user accounts. SCIM defines REST APIs for creating, updating, and deleting user accounts, as well as managing group memberships and attribute synchronization. Organizations use SCIM to ensure user accounts are created when employees join, updated when roles change, and deleted when employees leave. SCIM integration prevents the accumulation of orphaned accounts that represent ongoing security risks.
SSO security considerations include multiple attack vectors that security teams must address. Token theft through session hijacking allows attackers to impersonate legitimate users. Cross-site scripting (XSS) attacks can extract tokens from browser memory or local storage. Man-in-the-middle attacks can intercept tokens during transmission if not properly encrypted. IdP compromise represents a catastrophic failure mode because successful attacks against the identity provider grant access to all connected applications. Misconfigured SAML implementations enable assertion manipulation attacks where attackers modify XML assertions to escalate privileges or impersonate other users. Organizations must implement token encryption, signature validation, and proper session security to mitigate these risks.
Without SSO, organizations face credential anarchy. Users maintain separate credentials for every application, leading to predictable security failures. Password reuse becomes endemic because users cannot remember dozens of unique passwords. Password quality degrades because users choose memorable passwords over secure ones. Multi-factor authentication enforcement becomes inconsistent because each application implements MFA differently or not at all. Password reset requests consume help desk resources and create security gaps when users choose weak reset passwords.
SSO consolidates authentication to a single, hardened point where organizations can enforce strong authentication policies uniformly. Instead of implementing MFA across dozens of applications with varying capabilities, organizations implement MFA once at the IdP and extend it to all connected applications. This approach ensures consistent authentication strength regardless of individual application capabilities. SSO also enables sophisticated authentication policies like risk-based authentication that considers user location, device trust, and behavioral patterns. These policies are impractical to implement across multiple applications but become feasible with centralized authentication.
The business impact extends beyond security improvements. SSO reduces support costs by eliminating most password reset requests. Users become more productive because they spend less time managing credentials and waiting for password resets. New employee onboarding becomes faster because access provisioning happens centrally rather than application by application. SSO also enables immediate access revocation across all applications when employees depart, reducing the risk of departing employees retaining access to critical systems.
However, SSO failure consequences are severe and concentrated. When the identity provider fails, users lose access to all connected applications simultaneously. This represents a single point of failure that can shut down entire organizations. SSO outages often have broader impact than individual application outages because they affect multiple systems at once. Organizations must implement high availability and disaster recovery for SSO infrastructure with the same rigor applied to other critical business systems.
Common misconceptions about SSO create deployment and security gaps. Some organizations believe SSO eliminates the need for application-level access controls. In reality, SSO handles authentication (proving identity) but applications still require authorization (granting access). SSO tells applications who the user is, not what they should be allowed to do. Organizations also underestimate the complexity of SSO implementation, particularly around session management and token security. SSO is not simply enabling SAML or OIDC; it requires careful planning around session timeouts, token validation, and attribute mapping. Finally, some organizations view SSO as purely a user experience improvement rather than a security capability. While SSO does improve user experience, the primary value is security consolidation and policy enforcement.
CDA builds SSO into the Identity Access and Trust (IAT) domain as foundational identity infrastructure. IAT sits as the fourth ring in the Planetary Defense Model because identity verification must occur before access decisions can be made reliably. SSO provides the authentication foundation that enables other IAT capabilities like privileged access management, identity governance, and access analytics.
Our approach to SSO reflects the Zero Possession Architecture (ZPA) methodology: trust nothing, possess nothing, verify everything. Traditional SSO implementations focus on reducing authentication friction, which often leads to security compromises like extended session timeouts or relaxed token validation. CDA's approach prioritizes verification at every step. We implement continuous authentication that reassesses user risk throughout the session rather than relying on initial authentication. We use short-lived tokens that require frequent renewal to limit exposure from token theft. We verify device state and user behavior patterns as part of every access decision.
CDA's Nexus platform serves as the SSO provider for the CDA ecosystem, but our implementation differs from conventional SSO platforms in several ways. First, we treat SSO as intelligence infrastructure rather than just authentication infrastructure. Every authentication event generates telemetry about user behavior, device state, and access patterns. This telemetry feeds our threat intelligence and defense capabilities in real time. Second, we integrate SSO with our broader security posture rather than treating it as an isolated capability. SSO policies adapt based on vulnerability assessments, threat intelligence, and risk governance decisions. Third, we implement SSO with the assumption that the identity provider itself will be compromised. Our architecture includes detection and response capabilities for IdP compromise scenarios.
Our missions deploy SSO with OpenID Connect as the primary protocol because OIDC provides better integration with modern applications and APIs. We configure Conditional Access integration that evaluates device trust, user risk, and application sensitivity for every access request. Our session management policies align with organizational risk tolerance but default to aggressive timeouts and continuous verification. We implement SCIM integration for automated lifecycle management and require MFA for all SSO authentication. Our approach recognizes that SSO is not a destination but a foundation for more sophisticated identity and access management capabilities.
• SSO centralizes authentication to enable consistent security policies across all applications, but requires careful implementation to avoid creating single points of failure
• Modern SSO relies on federation protocols (SAML 2.0, OpenID Connect) that exchange identity assertions between trusted identity providers and service providers
• SSO security depends on proper token management, session security, and continuous verification rather than just initial authentication strength
• SSO enables immediate access revocation and automated lifecycle management through protocols like SCIM, making it essential for modern identity governance
• Organizations must implement SSO with high availability and incident response capabilities because SSO failures affect multiple applications simultaneously
• Zero Trust Access Control • Multi-Factor Authentication Architecture • Identity Governance Frameworks • Session Management Security • OAuth 2.0 and API Security
• NIST Special Publication 800-63B: Authentication and Lifecycle Management (2017) • OASIS Security Assertion Markup Language (SAML) V2.0 Technical Overview (2008) • RFC 6749: The OAuth 2.0 Authorization Framework (2012) • CIS Controls v8: Control 6 - Access Control Management (2021)