Single sign-on

1 Concepts and definitions

Single sign-on is a login approach in which a user authenticates once and then gains access to multiple connected systems without entering credentials again for each one. The method is built around a central trust point, usually an identity provider, that confirms the user’s identity and supplies proof that other applications can accept.

SSO is used in many environments, from internal enterprise networks to cloud services and consumer websites. It is valued for streamlining access, reducing the number of passwords users must remember, and giving administrators a more unified way to manage authentication.

1.1 Authentication vs. authorization

Authentication is the process of verifying who a user is, usually by checking credentials such as a password, security token, or biometric factor. Authorization is a separate step that determines what an authenticated user is allowed to do within a system. In SSO, the central login process primarily handles authentication, while each application still enforces its own authorization rules.

This distinction is important because a user may be authenticated through SSO but still have limited access in a particular application. In practice, SSO reduces repeated identity checks, but it does not eliminate the need for application-specific permissions.

1.2 Identity provider and service provider roles

An identity provider, often abbreviated IdP, is the system that verifies credentials and issues proof of authentication. A service provider, or relying party, is the application or service that accepts that proof and grants access.

These roles create a division of labor. The identity provider manages sign-in, while the service provider relies on the resulting assertion, token, or session to identify the user. This arrangement allows multiple applications to share a common authentication source without storing separate passwords for each one.

1.3 Session management

Session management refers to the handling of a user’s authenticated state after login. In SSO, a session may be established with the identity provider, with each connected application, or with both. The session lets the user move between services without being prompted to authenticate again.

Session lifetime, renewal, and termination are central concerns. A well-designed SSO system balances convenience with security by setting limits on how long a session remains valid and by requiring reauthentication for sensitive actions.

1.4 Trust relationships

SSO depends on trust relationships between the identity provider and the connected applications. The service provider must have confidence that the authentication evidence it receives is genuine and was issued by a trusted source. This trust is usually established through shared configuration, certificates, metadata, or prearranged protocol settings.

Because one trusted authority can support many applications, trust relationships simplify integration. At the same time, they create a need for careful governance, since errors in configuration or compromise of the trusted source can affect multiple systems.

2 How single sign-on works

At a basic level, SSO follows a sequence in which the user begins at an application, is redirected to an identity provider for sign-in, and then returns to the application with proof of authentication. That proof may be a token, assertion, or session reference depending on the protocol used.

Once authenticated, the user can access additional connected applications without repeating the full login process. Each application validates the proof according to its own rules and then creates or continues a local session.

2.1 Initial login flow

The initial login flow usually begins when the user tries to access a protected resource. The application recognizes that the user is not yet authenticated and sends the browser or client to the identity provider. There, the user enters credentials and may complete additional verification steps.

After successful sign-in, the identity provider sends a response back to the application. The response confirms the user’s identity and may include information needed to start a session or retrieve user attributes.

2.2 Token or assertion issuance

Following authentication, the identity provider issues a token or assertion that serves as evidence of the login. This artifact is digitally protected so that the receiving application can verify that it was created by the trusted issuer and has not been altered.

Different systems use different formats and lifetimes for these artifacts. Some are meant only for immediate use during a browser exchange, while others can support repeated requests until they expire or are revoked.

2.3 Accessing multiple applications

After the first application accepts the identity proof, the user can open other connected applications. Each one either checks the existing identity provider session or validates a new token obtained through the same central login. From the user’s perspective, the transition often appears seamless.

The exact behavior depends on the deployment model and protocol. In many cases, the user may still need to authorize access in a specific app or grant consent for shared data, even though no additional password entry is required.

2.4 Session renewal and expiration

SSO sessions do not last indefinitely. When a session expires, the user may be asked to sign in again, especially if a risk policy, time limit, or inactivity timeout has been reached. Some systems support silent renewal, allowing a fresh token to be issued without direct user interaction.

Expiration serves both security and administrative purposes. It limits the window in which a stolen credential or token can be misused and ensures that the authentication state remains current.

3 Common protocols and standards

Several standards are widely associated with SSO. Each one addresses authentication and federation in a different way, and each has its own terminology, message formats, and typical use cases.

These protocols are often used together with directory services, certificate infrastructure, and security policies. The choice of standard usually depends on whether the environment is web-based, enterprise-oriented, mobile, or API-heavy.

3.1 SAML

Security Assertion Markup Language, or SAML, is a widely used standard for exchanging authentication and authorization data between an identity provider and a service provider. It is especially common in enterprise web SSO, where a browser is redirected between systems during login.

SAML messages are typically XML-based and are signed to preserve integrity and trust. The standard is known for strong federation support and for fitting well into environments where organizations connect separate identity domains.

3.1.1 Assertions and metadata

A SAML assertion is the statement that carries the authentication result and related attributes about the user. It may include details such as the time of authentication, the identity of the issuer, and optional user attributes. The service provider uses this information to establish a session and, if needed, map the user to local permissions.

Metadata helps the two sides configure trust. It describes endpoints, certificates, and supported bindings, reducing the need for manual setup and making federation easier to manage.

3.1.2 Browser-based federation

SAML is often implemented through browser redirects and form posts. The user moves from the service provider to the identity provider, signs in, and then returns with a signed response. This browser-mediated process is a hallmark of SAML federation.

Because the browser is part of the exchange, SAML works well for interactive web applications. It is less commonly used for native mobile clients or machine-to-machine communication, where other protocols are often more practical.

3.2 OAuth

OAuth is an authorization framework that allows a user to grant an application limited access to resources without sharing the user’s password with that application. Although it was not originally designed as an authentication protocol, it is frequently used as part of modern sign-in systems.

In SSO contexts, OAuth is commonly paired with an identity layer so that login and delegated access can be handled together. This makes it especially useful in services that need both identity verification and API access.

3.2.1 Authorization frameworks

OAuth defines how a client obtains permission to act on behalf of a user. It uses scopes, consent, and access tokens to limit what the client can do. This design is suited to situations where an application needs access to email, profile data, or other protected resources.

Because OAuth focuses on authorization rather than identity, it is usually combined with another protocol when the goal is single sign-on. That combination allows a provider to confirm who the user is while also controlling what the application may access.

3.2.2 Token usage in SSO

In systems that use OAuth for SSO-related flows, tokens are the main credential artifact. An access token may allow API calls, while a separate identity component can communicate who the user is. Tokens are typically short-lived and may be refreshed when allowed by policy.

This token-based design supports modern application architectures, including mobile apps and single-page web applications. It also reduces reliance on repeated password entry while preserving fine-grained control over access.

3.3 OpenID Connect

OpenID Connect is an identity layer built on top of OAuth 2.0. It adds standardized authentication features so that applications can verify the user’s identity in a structured way. This has made it one of the most common standards for contemporary web and cloud SSO.

It uses familiar OAuth mechanisms such as authorization flows and tokens, but adds identity-specific data and discovery features. As a result, it is often easier to integrate into modern web services than older federation models.

3.3.1 ID tokens

An ID token is the core OpenID Connect artifact that states who the user is and how the authentication occurred. It is normally signed so that the receiving application can verify its origin and integrity. The token may include a subject identifier, issuer information, and timestamps.

ID tokens are not usually used as general access credentials for APIs. Instead, they are meant to communicate identity to the application that initiated the sign-in flow.

3.3.2 UserInfo endpoint

The UserInfo endpoint provides additional profile claims after authentication. An application can call it with an access token to obtain more information about the user, such as a display name or email address, depending on the consent and configuration in place.

This endpoint helps separate identity confirmation from attribute retrieval. It allows the system to keep the ID token compact while still supporting richer user data when needed.

3.4 Kerberos

Kerberos is a network authentication protocol designed to provide secure, ticket-based sign-in within trusted environments. It is commonly associated with enterprise and internal network SSO, particularly in systems that support integrated authentication.

Kerberos uses a central authority to issue time-limited tickets that prove a user has already been authenticated. Applications accept those tickets instead of prompting for a fresh password, making it useful for seamless access across multiple internal services.

4 SSO deployment models

SSO can be deployed in different ways depending on the size of the organization, the type of applications involved, and the level of external integration required. Some models focus on internal productivity, while others are designed for cross-company federation or public web services.

The same organization may use more than one deployment model at once. For example, employees may use enterprise SSO for internal tools and social login for a public-facing service.

4.1 Enterprise SSO

Enterprise SSO is used inside organizations to give employees access to business applications through a common login. It is often integrated with corporate directories and identity governance systems, making it easier to manage users at scale.

This model usually supports internal applications, software-as-a-service platforms, and productivity tools. It reduces repeated password entry and makes account administration more consistent across the workplace.

4.2 Web-based SSO

Web-based SSO connects browser-accessed applications through a shared sign-in experience. It is common in online services where the user begins on one site and then moves to another without logging in again.

Because browsers can follow redirects and store session cookies, web-based SSO is well suited to standards such as SAML and OpenID Connect. It is widely used for consumer portals, cloud dashboards, and shared business applications.

4.3 Federated identity

Federated identity allows separate organizations or domains to trust each other’s authentication processes. A user authenticated by one domain can access services in another without creating a new local account for every system.

This model is useful when partners, universities, subsidiaries, or service ecosystems need shared access while retaining their own identity management. Federation reduces duplication and can improve user experience across organizational boundaries.

4.4 Social login integration

Social login lets users sign into an application with an account from a large consumer identity platform. The service acts as the identity provider, and the application relies on the sign-in result rather than asking the user to create a separate password.

This approach is popular on consumer websites because it lowers registration friction. It can speed onboarding, though it also ties the application’s login experience to the policies and availability of the external provider.

5 Security considerations

SSO can strengthen security by centralizing authentication controls, but it also concentrates risk. The design must account for the possibility that one compromised account or misconfigured provider could affect several connected services.

Good security practice typically includes strong authentication, short-lived tokens, secure transport, careful logging, and regular review of trust relationships. The goal is to preserve convenience without undermining resilience.

5.1 Single point of failure

A central identity provider can become a single point of failure if it is unavailable or misconfigured. When that happens, users may be unable to reach multiple dependent applications, even if those applications are otherwise functioning.

Organizations reduce this risk by using redundancy, disaster recovery planning, and robust monitoring. Some also keep limited fallback access procedures for critical services.

5.2 Credential theft and phishing risks

Because SSO concentrates access behind one set of credentials, stolen login information can have broader impact than a password used for only one site. Phishing campaigns often target the central sign-in page for this reason, hoping to capture credentials or session data.

Protective measures include user education, phishing-resistant authentication, and careful verification of login URLs and certificates. Limiting the lifetime of tokens also helps reduce exposure if credentials are compromised.

5.3 Session hijacking

Session hijacking occurs when an attacker steals or reuses a valid session or token to impersonate the user. In SSO systems, this may allow unauthorized access to several services until the session is invalidated.

Defenses include secure cookie settings, transport encryption, device binding where appropriate, and reauthentication for high-risk actions. Session monitoring and anomaly detection can also help identify unusual use.

5.4 Multi-factor authentication

Multi-factor authentication, or MFA, adds a second or additional verification step beyond a password. In SSO environments, MFA is often applied at the identity provider so that one strong sign-in can protect many downstream applications.

This approach improves security without forcing each application to manage its own second factor. It is especially effective when combined with risk-based policies and time-based session controls.

6 Benefits and limitations

SSO offers clear usability and administrative advantages, but it also introduces dependencies and design trade-offs. The benefits are strongest when many applications share a common identity infrastructure and when users regularly move among them.

At the same time, SSO works best when organizations accept the operational discipline required to maintain the underlying trust and protocol configuration.

6.1 User convenience

From the user’s perspective, SSO reduces the friction of repeated logins. A single authentication event can unlock access to email, documents, internal tools, and other services, making daily work smoother and faster.

This convenience can also improve adoption of approved systems. Users are less likely to reuse weak passwords or resort to informal workarounds when access is straightforward.

6.2 Administrative efficiency

For administrators, SSO centralizes authentication management and can simplify policy enforcement. Password resets, account reviews, and authentication settings can be handled in one place rather than across many separate systems.

This centralization can reduce support requests and make compliance monitoring more consistent. It also gives organizations a clearer picture of who is authenticating and when.

6.3 Reduced password sprawl

Without SSO, users often accumulate many accounts and passwords across services. This password sprawl increases the chance of reuse, forgotten credentials, and insecure habits such as writing passwords down or choosing simple variations.

By decreasing the number of separate logins, SSO helps limit these problems. It can be especially beneficial in environments where employees or customers interact with numerous applications.

6.4 Dependency on provider availability

A major limitation of SSO is dependence on the identity provider. If the provider is offline, slow, or misconfigured, access to connected services may be delayed or blocked.

This dependence means that reliability planning is important. Organizations that rely heavily on SSO usually invest in redundancy, capacity planning, and fallback mechanisms to keep access available.

7 Implementation and integration

Implementing SSO is not just a matter of choosing a protocol. It also requires directory mapping, account lifecycle management, application configuration, and testing across a range of systems and platforms.

Successful integration often depends on how well existing identity sources, application permissions, and operational procedures fit together. The more heterogeneous the environment, the more planning is typically required.

7.1 Directory services

Directory services store identity records such as usernames, group memberships, and contact information. They often serve as the source of truth for enterprise SSO, providing the data used to authenticate users and populate account attributes.

Common integration patterns connect SSO systems to directory platforms so that user information remains synchronized. This reduces manual account handling and helps keep authentication data current.

7.2 Application onboarding

Application onboarding is the process of connecting a new service to the SSO environment. It includes exchanging metadata, configuring redirect endpoints, assigning certificates or keys, and testing the login sequence.

Onboarding may be simple for standards-compliant applications but more complex for older or custom-built systems. Each application must be configured to trust the identity provider and to interpret the resulting authentication data correctly.

7.3 User provisioning and deprovisioning

Provisioning is the creation or activation of user access, while deprovisioning removes or disables it when no longer needed. In SSO deployments, these tasks may be automated so that account changes in the directory are reflected across connected services.

This lifecycle management is important for security and efficiency. It helps ensure that people receive appropriate access quickly and that departed users do not retain unnecessary permissions.

7.4 Compatibility and legacy systems

Legacy applications may not support modern SSO protocols or may rely on older login methods. In such cases, integration often requires adapters, gateways, or custom connectors that translate between systems.

Compatibility challenges can shape the overall architecture of an SSO deployment. Organizations sometimes phase in support over time, preserving older systems while gradually moving toward more standardized authentication methods.

8 Related technologies

SSO sits within a broader ecosystem of identity and access tools. These related technologies help manage accounts, synchronize directories, protect passwords, and control the end of authenticated sessions.

Understanding the surrounding tools clarifies where SSO fits and what problems it does not solve on its own.

8.1 Identity and access management

Identity and access management, often abbreviated IAM, refers to the policies and systems used to control digital identities and permissions. SSO is one component of IAM, focused specifically on authentication across multiple applications.

IAM platforms may also handle access reviews, role assignment, compliance reporting, and privileged account management. Together, these capabilities support a more structured approach to user access.

8.2 Directory synchronization

Directory synchronization keeps identity data aligned across multiple systems. It may copy users, groups, and attributes from a master directory to other services so that access decisions remain consistent.

This process complements SSO by ensuring that the user identities referenced during login also exist in the connected applications. It is particularly useful in large organizations with many downstream services.

8.3 Password managers

Password managers store and autofill credentials for many accounts. They solve a different problem from SSO, but both aim to reduce the burden of remembering multiple passwords.

Unlike SSO, a password manager does not necessarily provide a shared authentication relationship among applications. It helps users manage credentials, whereas SSO establishes a common login framework.

8.4 Single logout

Single logout is the coordinated termination of authenticated sessions across multiple connected applications. When a user signs out once, the system attempts to end related sessions so that access is not left active elsewhere.

This feature is harder to implement consistently than single sign-on because each application may handle sessions differently. Even so, it is an important complement to SSO, especially in shared or public-use environments.