Single sign-on, commonly abbreviated SSO, is an authentication arrangement that allows a user to authenticate once through a trusted identity provider and then access multiple authorised applications or services without separately entering credentials for each application. The central purpose is to simplify authentication while allowing an organisation to manage identities and authentication centrally. Instead of maintaining independent passwords for every application, the user authenticates to an identity provider, which then provides assertions or tokens that participating applications can trust.
SSO is particularly common in enterprise environments and cloud services. It can reduce password proliferation, improve centralised account management and make it easier to enforce common authentication policies, although the identity provider becomes a highly important security component whose compromise can affect many connected services.
An SSO architecture normally contains an identity provider and one or more relying parties or service providers. The identity provider is responsible for authenticating the user and communicating the authentication result to an application. The application trusts the identity provider according to a defined federation protocol and configuration. Common protocols and standards include SAML 2.0, OpenID Connect and OAuth-related technologies, although OAuth itself is primarily an authorisation framework rather than an authentication protocol.
OpenID Connect adds an identity layer on top of OAuth 2.0. SAML is widely used in enterprise web SSO, while OpenID Connect is common in modern web and mobile application architectures. The protocol determines how identities, authentication results, tokens and assertions are exchanged and validated.
A typical SSO flow begins when a user attempts to access an application without an active authenticated session. The application redirects the user to the identity provider or otherwise initiates an authentication transaction. The identity provider authenticates the user, potentially using a password, MFA, passkey, security key or another method. After successful authentication, the identity provider issues an appropriate assertion or token for the requesting application.
The application validates the cryptographic signature, issuer, audience, expiry and other required claims before establishing its own application session. The user can then access the application without separately supplying the application's local password. The precise sequence differs between SAML, OpenID Connect and other federation mechanisms.
SSO is closely related to identity federation but the concepts are not identical. Federation allows identities and authentication information to be trusted across organisational or security boundaries, while SSO describes the user experience and authentication pattern of accessing multiple services through a common authentication process. A federation relationship can support SSO, but federation can also be used for other identity-related purposes. SSO also differs from password managers.
A password manager stores or generates separate credentials for different services, whereas SSO allows participating applications to rely on a central identity provider. Similarly, SSO does not mean that every application necessarily shares one password; well-designed SSO often eliminates the need for application-specific passwords altogether.
Centralised authentication can improve security administration. When an employee leaves an organisation, disabling the central identity account can prevent access to many federated applications, although effective deprovisioning also depends on application configuration and token/session behaviour. Administrators can centrally enforce MFA, password policies, device conditions and other authentication controls. SSO can also reduce password reuse and the number of credentials users need to remember. From an operational perspective, it can reduce help-desk requests related to forgotten application passwords. However, centralisation creates concentration risk: if an attacker compromises a highly privileged identity-provider account, the attacker may gain access to multiple applications. Strong protection of identity-provider accounts, administrative interfaces, recovery processes and federation configuration is therefore essential.
SSO implementations depend heavily on secure token and session management. Tokens should be validated correctly, have appropriate lifetimes and scopes, and be protected from theft or misuse. Applications must validate claims such as issuer and audience so that a token intended for one service cannot simply be accepted by another. Redirect URIs, signing keys, client credentials and federation metadata must also be managed securely.
Session termination is another consideration: logging out of one application does not necessarily invalidate every existing session unless the architecture supports appropriate single logout mechanisms. Administrators must therefore understand the distinction between central authentication, application sessions and token lifetimes rather than assuming that one logout or account change automatically terminates every access path.
SSO can provide significant usability benefits, but it also introduces dependencies and governance requirements. Applications must support the relevant federation protocol correctly, identities need to be mapped consistently, and roles or group memberships may need to be synchronised. A central identity provider can become a single point of operational failure if applications cannot authenticate users when it is unavailable. Organisations may therefore design resilient identity infrastructure and appropriate emergency procedures. SSO can also complicate mergers, acquisitions and multi-organisation environments where identity domains differ. Despite these challenges, centralised identity is a fundamental component of modern enterprise access architectures because it provides a consistent location for authentication policy and lifecycle management.
SSO should be understood as a mechanism for federated or centralised authentication rather than as an authorisation system by itself. Successfully authenticating through an identity provider does not automatically mean the user is allowed to perform every action within an application. Applications still need authorisation rules based on roles, groups, attributes or permissions. SSO can therefore work alongside MFA, role-based access control, least-privilege access, conditional access and zero-trust security.
Its principal value is that multiple services can trust a common authentication authority, reducing duplicated credential management while enabling consistent authentication controls. Its principal architectural risk is that the identity provider becomes a high-value security boundary requiring strong protection, monitoring, redundancy and carefully managed federation relationships.
