[Atomic Glue](atomicglue.co)
BACKEND
Home › Glossary › Backend· 380 ·

Single Sign-On (SSO)

\\sing-guhl sin-on ess-ess-oh\\n.
Filed underBackendSecurityArchitectureSoftware Engineering
In brief · quick answer

Single Sign-On (SSO) is an authentication system that lets users log in once with one set of credentials and gain access to multiple independent applications without re-entering credentials.

§ 1 Definition

Single Sign-On (SSO) solves the problem of credential sprawl. Instead of maintaining separate usernames and passwords for every application, users authenticate once with an identity provider (IdP) and gain access to all connected applications (service providers) without additional logins. The most common SSO implementations use SAML 2.0 (older, enterprise-focused) or OpenID Connect (modern, web-focused). SSO is not just a convenience feature. It centralizes security policies: password complexity, MFA requirements, account lockout, and session management are enforced in one place. When an employee leaves an organization, disabling their SSO account revokes access to every connected application instantly. SSO also provides audit trails of who accessed which application and when. The tradeoffs: SSO creates a single point of failure. If the identity provider is down, users cannot access any application. SSO also introduces a target for attackers, making the IdP a high-value security asset requiring MFA, monitoring, and incident response. Enterprise-grade SSO requires redundancy, backup authentication methods, and robust security controls.

§ 2 How SSO Works

SSO involves three parties. The User (the person trying to access an application). The Service Provider (SP) is the application the user wants to access. The Identity Provider (IdP) authenticates the user and issues tokens. The flow: User attempts to access an application. The application redirects the user to the IdP for authentication. The user authenticates with the IdP (using password, MFA, security key, etc.). The IdP generates a signed token (SAML assertion or OIDC ID token) containing the user's identity and attributes. The user is redirected back to the application with the token. The application validates the token signature, extracts user identity, and creates a local session. The user is logged in. If the user then accesses another connected application, the same IdP session is reused without re-authentication.

§ 3 SAML vs OpenID Connect

SAML 2.0 (Security Assertion Markup Language) is the older protocol, dominant in enterprise environments. It uses XML for assertions and typically redirects via browser POST bindings. OpenID Connect (OIDC) is the modern protocol, based on OAuth 2.0. It uses JSON for claims and is designed for web and mobile applications. OIDC is simpler to implement, more developer-friendly, and better suited for modern applications. SAML has broader enterprise support (Active Directory, Okta, OneLogin). The trend is toward OIDC for new implementations, with SAML maintained for legacy enterprise integration. Many identity providers support both protocols, allowing a gradual transition.

§ 4 SSO Providers and Self-Hosting

Commercial SSO providers include Okta (enterprise focus), Auth0 (developer-focused, OIDC), Azure Active Directory / Entra ID (Microsoft ecosystem), Google Workspace, OneLogin, and Ping. Open-source options include Keycloak (Red Hat, full-featured), Authentik, Dex (CoreOS), and Casdoor. Self-hosting SSO gives you full control over user data and avoids per-user pricing that becomes expensive at scale. The tradeoff is operational overhead: you must manage uptime, backups, security updates, and disaster recovery for the identity provider. For small teams and startups, Auth0 or Clerk is more practical. For enterprises with dedicated ops teams, Keycloak or Entra ID provides better control. For business applications, SSO is often a requirement for enterprise sales, as most companies mandate SSO for third-party applications they purchase.

§ 5 Note

Common misunderstanding: SSO is not the same as social login (Sign in with Google). Social login is a specific type of SSO that uses consumer identity providers. Enterprise SSO typically uses SAML or OIDC with corporate identity providers like Okta, Entra ID, or Keycloak. Another misconception: SSO eliminates passwords. Users still have at least one password (the IdP password). SSO reduces the number of passwords from many to one. It does not eliminate authentication. Also: SSO does not automatically make your application more secure. It centralizes the authentication attack surface. If the IdP is compromised, every connected application is at risk.

§ 6 In code

```javascript
// Express SSO with OpenID Connect
import { express } from 'express';
import { expressjwt } from 'express-jwt';
import jwksClient from 'jwks-rsa';

// Validate JWTs from the IdP
app.use(expressjwt({
  secret: jwksClient.expressJwtSecret({
    jwksUri: 'https://<idp>/.well-known/jwks.json',
  }),
  algorithms: ['RS256'],
  issuer: 'https://<idp>/',
}).unless({ path: ['/login'] }));

// Redirect to IdP for login
app.get('/login', (req, res) => {
  const authUrl = new URL('https://<idp>/authorize');
  authUrl.searchParams.set('client_id', process.env.CLIENT_ID);
  authUrl.searchParams.set('redirect_uri', 'https://app.com/callback');
  authUrl.searchParams.set('response_type', 'code');
  authUrl.searchParams.set('scope', 'openid profile email');
  res.redirect(authUrl.toString());
});

// Handle callback
app.get('/callback', async (req, res) => {
  const tokens = await exchangeCodeForTokens(req.query.code);
  const user = jwt.decode(tokens.id_token);
  req.session.user = { id: user.sub, email: user.email };
  res.redirect('/dashboard');
});
```

§ 7 Common questions

Q. Do I need SSO for my application?
A. If you are selling B2B software, yes. Enterprise buyers mandate SSO. If your application is consumer-facing, SSO (via social login) is a convenience feature, not a requirement.
Q. What happens if my SSO provider is down?
A. Users cannot log in to any connected application. Mitigations include provider redundancy (multiple IdPs), backup authentication methods, and local fallback authentication for critical systems.
Q. Can I self-host SSO?
A. Yes. Keycloak and Authentik are popular open-source SSO solutions. Self-hosting gives you data control but adds operational overhead. For most small-to-medium businesses, a managed provider is more practical.
Key takeaways
  • SSO lets users authenticate once with an IdP to access multiple applications.
  • SAML 2.0 (XML) is the legacy enterprise protocol. OpenID Connect (JSON) is the modern standard.
  • SSO centralizes security policy enforcement, MFA, and account lifecycle management.
  • SSO creates a single point of failure. The IdP must be highly available and secure.
How Atomic Glue helps

Atomic Glue implements SSO for B2B applications that need enterprise authentication. We support both SAML 2.0 (for legacy enterprise IdPs like Okta and ADFS) and OpenID Connect (for modern providers like Auth0, Entra ID, and Keycloak). Our SSO implementations include IdP-initiated and SP-initiated flows, automatic user provisioning (SCIM), and audit logging. SSO is a standard requirement in our enterprise Web Development services. Get in touch to integrate SSO into your application.

Get in touch
# Single Sign-On (SSO)

Single Sign-On (SSO) is an authentication system that lets users log in once with one set of credentials and gain access to multiple independent applications without re-entering credentials.

Category: Backend (also: Security, Architecture, Software Engineering)

Author: Atomic Glue Development Team

## Definition

Single Sign-On (SSO) solves the problem of credential sprawl. Instead of maintaining separate usernames and passwords for every application, users authenticate once with an identity provider (IdP) and gain access to all connected applications (service providers) without additional logins. The most common SSO implementations use SAML 2.0 (older, enterprise-focused) or OpenID Connect (modern, web-focused). SSO is not just a convenience feature. It centralizes security policies: password complexity, MFA requirements, account lockout, and session management are enforced in one place. When an employee leaves an organization, disabling their SSO account revokes access to every connected application instantly. SSO also provides audit trails of who accessed which application and when. The tradeoffs: SSO creates a single point of failure. If the identity provider is down, users cannot access any application. SSO also introduces a target for attackers, making the IdP a high-value security asset requiring MFA, monitoring, and incident response. Enterprise-grade SSO requires redundancy, backup authentication methods, and robust security controls.

## How SSO Works

SSO involves three parties. The User (the person trying to access an application). The Service Provider (SP) is the application the user wants to access. The Identity Provider (IdP) authenticates the user and issues tokens. The flow: User attempts to access an application. The application redirects the user to the IdP for authentication. The user authenticates with the IdP (using password, MFA, security key, etc.). The IdP generates a signed token (SAML assertion or OIDC ID token) containing the user's identity and attributes. The user is redirected back to the application with the token. The application validates the token signature, extracts user identity, and creates a local session. The user is logged in. If the user then accesses another connected application, the same IdP session is reused without re-authentication.

## SAML vs OpenID Connect

SAML 2.0 (Security Assertion Markup Language) is the older protocol, dominant in enterprise environments. It uses XML for assertions and typically redirects via browser POST bindings. OpenID Connect (OIDC) is the modern protocol, based on OAuth 2.0. It uses JSON for claims and is designed for web and mobile applications. OIDC is simpler to implement, more developer-friendly, and better suited for modern applications. SAML has broader enterprise support (Active Directory, Okta, OneLogin). The trend is toward OIDC for new implementations, with SAML maintained for legacy enterprise integration. Many identity providers support both protocols, allowing a gradual transition.

## SSO Providers and Self-Hosting

Commercial SSO providers include Okta (enterprise focus), Auth0 (developer-focused, OIDC), Azure Active Directory / Entra ID (Microsoft ecosystem), Google Workspace, OneLogin, and Ping. Open-source options include Keycloak (Red Hat, full-featured), Authentik, Dex (CoreOS), and Casdoor. Self-hosting SSO gives you full control over user data and avoids per-user pricing that becomes expensive at scale. The tradeoff is operational overhead: you must manage uptime, backups, security updates, and disaster recovery for the identity provider. For small teams and startups, Auth0 or Clerk is more practical. For enterprises with dedicated ops teams, Keycloak or Entra ID provides better control. For business applications, SSO is often a requirement for enterprise sales, as most companies mandate SSO for third-party applications they purchase.

## Note

Common misunderstanding: SSO is not the same as social login (Sign in with Google). Social login is a specific type of SSO that uses consumer identity providers. Enterprise SSO typically uses SAML or OIDC with corporate identity providers like Okta, Entra ID, or Keycloak. Another misconception: SSO eliminates passwords. Users still have at least one password (the IdP password). SSO reduces the number of passwords from many to one. It does not eliminate authentication. Also: SSO does not automatically make your application more secure. It centralizes the authentication attack surface. If the IdP is compromised, every connected application is at risk.

## In code

## Common questions
Q: Do I need SSO for my application?
A: If you are selling B2B software, yes. Enterprise buyers mandate SSO. If your application is consumer-facing, SSO (via social login) is a convenience feature, not a requirement.
Q: What happens if my SSO provider is down?
A: Users cannot log in to any connected application. Mitigations include provider redundancy (multiple IdPs), backup authentication methods, and local fallback authentication for critical systems.
Q: Can I self-host SSO?
A: Yes. Keycloak and Authentik are popular open-source SSO solutions. Self-hosting gives you data control but adds operational overhead. For most small-to-medium businesses, a managed provider is more practical.

## Key takeaways

## Related entries


Last updated June 2026. Permalink: atomicglue.co/glossary/single-sign-on-sso

Schedule a call

30 min · Video call

1
Date
2
Time
3
Details