What is Single Sign-On (SSO)?

Single sign-on is an authentication method where one login at an identity provider grants access to many independent applications. The cast is two roles: the identity provider (IdP) authenticates users and vouches for them; each service provider (SP) — the apps you actually want — trusts that vouching instead of running its own login. One pedantic distinction worth keeping: apps sharing a directory but each prompting for the password is same sign-on; true SSO means you are asked once.

Key takeaways

The redirect dance, step by step

Why redirects at all? The browser’s same-origin policy: app.example.com cannot read a login cookie for idp.example.org, so identity must travel as a signed message through the browser rather than as a shared cookie — which is exactly what the flow does:

1  User opens app.example.com — no session
2  SP redirects to the IdP with an authentication request
3  User authenticates AT THE IDP (password + MFA) — or already has
   an IdP session, and this step is silently skipped
4  IdP issues a signed assertion (SAML XML) or ID token (OIDC JWT)
5  Browser delivers it to the SP's callback URL
6  SP validates: signature · issuer · audience · expiry · replay
7  SP starts its own local session — the user is in
8  Next app: steps 1–2, then straight from 3's silent path to 7

What the service-provider side looks like when a backend wraps it:

// JavaScript / Node.js — Back4app JS SDK
// Enterprise SSO: the IdP authenticates; the app trusts its signed token
// After the OIDC redirect dance, the client holds the IdP's tokens:
const user = await Parse.User.logInWith('keycloak', {
  authData: {
    id: subClaim,              // the IdP's stable subject ID
    access_token: accessToken, // verified server-side against the IdP
  },
});
// One IdP login now serves every app that trusts the same issuer.

// Flutter / Dart — Back4app Flutter SDK
// Enterprise SSO: the IdP authenticates; the app trusts its signed token
// After the OIDC redirect dance, the client holds the IdP's tokens:
final user = ParseUser.forQuery();
final response = await user.loginWith('keycloak', {
  'id': subClaim,              // the IdP's stable subject ID
  'access_token': accessToken, // verified server-side against the IdP
});
// One IdP login now serves every app that trusts the same issuer.

// iOS / Swift — Back4app Swift SDK
// Enterprise SSO: the IdP authenticates; the app trusts its signed token
// After the OIDC redirect dance, the client holds the IdP's tokens:
let user = try await User.loginWith(
    "keycloak",
    authData: [
        "id": subClaim,              // the IdP's stable subject ID
        "access_token": accessToken  // verified server-side against the IdP
    ]
)
// One IdP login now serves every app that trusts the same issuer.

// Android / Kotlin — Back4app Android SDK
// Enterprise SSO: the IdP authenticates; the app trusts its signed token
// After the OIDC redirect dance, the client holds the IdP's tokens:
val authData = mapOf(
    "id" to subClaim,              // the IdP's stable subject ID
    "access_token" to accessToken  // verified server-side against the IdP
)
ParseUser.logInWithInBackground("keycloak", authData).continueWith { task ->
    val user = task.result
    // One IdP login now serves every app that trusts the same issuer.
}

SP-initiated vs. IdP-initiated

Most explainers describe only the first and never name the second — yet enterprise IdPs love dashboard tiles, so SPs meet both. The SAML technical overview specifies the two profiles; the practical rule is in the table’s last row.

SAML vs. OIDC

And the triangle that untangles the acronyms, once: SAML and OIDC do authentication for SSO; OAuth 2.0 alone is authorization — OIDC is the identity layer that made OAuth’s plumbing safe to log in with. Social login is the same OIDC machinery with a consumer platform as the IdP and a single app as the audience; enterprise SSO changes the landlord and widens the session to a suite.

The parts nobody mentions

Single logout (SLO) is the hard half. Login fans in to one IdP; logout must fan out to every SP holding a local session — and the chain breaks if one app is unresponsive, browser third-party-cookie restrictions break front-channel notifications, and nothing reaches your other devices. In practice, “logged out everywhere” means short local sessions that re-check the (terminated) IdP session, not a reliable broadcast. Sessions run on three clocks: the IdP’s global session, each app’s local session, and the assertion’s own validity window. Logging out of an app while the IdP session lives means silent re-entry on the next visit — behavior users report as a bug and architects should recognize as the design. And the SSO tax: SaaS vendors routinely gate SAML/SSO support behind enterprise tiers at multiples of base pricing — a market fact worth budgeting for, since the security team’s requirement and the procurement line item arrive together.

The blast radius, honestly

SSO concentrates risk on purpose — that is what “single” means. One compromised IdP account opens every connected app; a compromised IdP itself — including theft of its assertion-signing keys, the “golden assertion” attack pattern — mints valid identity for anyone, everywhere. Vendors soften this; the engineering answer is to spend the concentration wisely: phishing-resistant MFA at the IdP (the one login is now worth passkey-grade protection), step-up authentication for sensitive apps rather than one blanket session, short global sessions where the stakes are high, signing-key rotation and monitoring, and break-glass local accounts for the day the IdP is down. The single point of failure never disappears — it gets armored, because armoring one point is exactly the economy SSO promised.

Integrating as a service provider

What “we support SSO” actually requires of an app team, in one list: register your callback/ACS URL with the IdP and exchange metadata (issuer, certificates); validate everything on every assertion — signature, issuer, audience, expiry, and replay binding; map the IdP’s claims onto your user model, keyed on the stable subject ID, never email alone; provision just-in-time (first SSO login creates the local user); handle IdP-initiated arrivals deliberately; and test logout expectations against the three-clock reality above. It is a well-worn path — which is why open-source IdPs like Keycloak exist for the other side of the handshake — but each item skipped is a security finding with a date attached.

Common use cases

• Workforce app suites — the canonical case: one morning login, every internal and SaaS tool after.
• B2B SaaS selling upmarket — “supports SSO” as the enterprise deal’s gating checkbox.
• Education and healthcare — federated access across institutions, where SAML’s roots run deepest.
• Centralized MFA and offboarding — one place to enforce factors; one switch that ends a departed employee’s access everywhere.
• Multi-app products — your own suite sharing one login via your own IdP, consumer-style.

Should you add SSO? A decision matrix

Limitations and trade-offs

• Availability concentrates with identity. The IdP’s downtime is everyone’s login outage; redundancy and break-glass paths are part of the feature, not additions to it.
• Logout is weaker than login. SLO’s fan-out fails partially by design; short local sessions, not logout broadcasts, deliver the real guarantee.
• The long tail stays passworded. Apps without SSO support keep their own credentials — password managers remain the mop-up layer.
• Session layering confuses users. Silent re-login and “I logged out but didn’t” tickets are the UX bill for the three-clock design; docs and predictable timeouts pay it down.
• Integration quality varies by SP. SSO’s security ceiling is set by the sloppiest assertion validation among your connected apps — the checklist above is per-app, forever.

SSO on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. An app here joins an SSO estate as a service provider through the same adapter mechanism that powers social login: Back4app ships auth adapters for Keycloak, LDAP, and generic OAuth2/OIDC issuers, so the code tabs’ flow — IdP authenticates, app receives tokens, logInWith verifies them server-side against the issuer — turns enterprise SSO into configuration plus a redirect handler. Identities key on the IdP’s stable subject in per-provider authData, first login provisions the user just-in-time, linkWith attaches additional methods for the break-glass path, and the session your app issues stays a revocable Parse session — so the three-clock layering ends, on your side, with a clock you fully control.