--- term: 'Single Sign-On (SSO)' seoTitle: 'Single Sign-On (SSO): How It Works, SAML vs. OIDC, Risks' headline: 'What is Single Sign-On (SSO)?' slug: single-sign-on-sso category: auth-security shortDefinition: 'Single sign-on is an authentication method where one login at an identity provider grants access to many independent applications.' relatedTerms: - identity-access-management-iam - oauth-2-social-login - multi-factor-authentication-mfa - session-management contrastsWith: - oauth-2-social-login aboutTerms: - 'Identity Provider (IdP)' - 'Service Provider (SP)' - 'SAML' - 'Single Logout (SLO)' faq: - question: 'What is SSO in simple terms?' answer: 'One login unlocks many apps: you prove who you are once to a central identity provider, and every connected application trusts that proof instead of asking for its own password. The morning login to the company portal that silently opens email, the wiki, and the CRM is SSO at work.' - question: 'How does SSO work?' answer: 'By redirects and signed tokens. The app sends an unauthenticated user to the identity provider; the user authenticates there — password plus MFA — and the IdP issues a digitally signed assertion the browser carries back; the app validates the signature against pre-exchanged certificates and starts a session. The next app skips the login because the IdP session already exists.' - question: 'What is an SSO token?' answer: 'A signed package of identity claims — subject, email, issuer, expiry. SAML calls it an assertion and writes it in XML; OpenID Connect calls it an ID token and writes it as a JWT. The app verifies the signature, never the password — the password never leaves the identity provider.' - question: 'Is SSO secure?' answer: 'Net positive when the identity provider enforces MFA: fewer passwords exist to phish, and policy, auditing, and lockout live in one place. The honest trade is concentration — one compromised IdP account, or the IdP itself, opens everything downstream. SSO makes the front door excellent and singular.' - question: 'What is the difference between SSO and a password manager?' answer: 'A password manager stores many secrets and autofills them — every app still runs its own login. SSO removes per-app passwords entirely: apps delegate authentication to the IdP and hold no credential for you at all. They complement each other; managers cover the long tail of apps without SSO support.' - question: 'Is social login the same as SSO?' answer: 'Same machinery, different landlord. Both are OIDC-style redirect flows to an identity provider — but social login uses a consumer platform''s IdP to sign in to one app, while enterprise SSO uses an organization-controlled IdP whose single session spans a whole suite of applications.' - question: 'SAML or OIDC for SSO?' answer: 'OIDC for anything new — JSON and JWTs over REST, friendly to mobile and SPAs, easier to implement and debug. SAML for compatibility — the XML-era protocol entrenched in enterprise identity providers. Products selling to enterprises typically end up speaking both.' - question: 'Do you still need MFA with SSO?' answer: 'Emphatically — SSO makes the one login more valuable, not less. The compensating virtue: enforcing MFA at the identity provider protects every connected application in a single move, which is precisely the centralization SSO exists to provide.' - question: 'What happens when the identity provider is down?' answer: 'No one starts a new session in any connected app — existing app sessions survive until they expire. This is the availability face of the single point of failure, and the reason IdP redundancy, break-glass admin accounts, and fallback paths belong in the rollout plan, not the postmortem.' - question: 'How long does an SSO session last?' answer: 'Two clocks, not one: the identity provider''s global session — hours to weeks, policy-configurable — and each app''s own local session. When an app''s session expires it re-checks with the IdP; if the global session lives, re-entry is silent. That layering is why "I logged out but got logged back in" happens by design.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'SAML 2.0 Technical Overview — OASIS' url: 'https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html' - name: 'OpenID Connect Core 1.0' url: 'https://openid.net/specs/openid-connect-core-1_0.html' - name: 'NIST SP 800-63C — Federation and Assertions' url: 'https://pages.nist.gov/800-63-3/sp800-63c.html' - name: 'RFC 6749 — The OAuth 2.0 Authorization Framework' url: 'https://datatracker.ietf.org/doc/html/rfc6749' cta: title: 'Enterprise login, one adapter away' text: 'Point Back4app''s auth adapters at your customer''s identity provider — Keycloak, LDAP, or any OIDC issuer — and Back4app verifies its tokens server-side, maps identities to users, and issues your app''s sessions.' linkText: 'Start building free' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-07-30' translationKey: 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 | Question | Answer | | --- | --- | | The cast | IdP authenticates and vouches · SPs trust the vouching | | The mechanism | Redirects + signed assertions — the password never leaves the IdP | | The protocols | SAML (XML, enterprise legacy) · OIDC (JWT on OAuth, the modern default) | | The trade | One excellent front door — and one door worth everything behind it | | The fine print | Single logout is hard · sessions run on multiple clocks · SSO costs extra in SaaS | ## 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: ```text 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:** ```javascript // 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 // 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. ``` **Swift:** ```swift // 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. ``` **Kotlin:** ```kotlin // 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. } ``` ```mermaid flowchart LR accTitle: Single sign-on flow between service providers and the identity provider accDescr: An unauthenticated user at a service provider is redirected to the identity provider, authenticates once with MFA, and receives a signed assertion delivered back to the service provider, which validates it and starts a local session. A second application repeats the redirect but the existing identity provider session makes login silent. U["User"] --> SP1["App A (SP)
no session"] SP1 -->|"redirect + auth request"| IDP["Identity provider
login + MFA · global session"] IDP -->|"signed assertion"| SP1 SP1 -->|"validate → local session"| OK1["App A open"] U2["Same user, later"] --> SP2["App B (SP)"] SP2 -->|"redirect"| IDP IDP -.->|"session exists —
silent assertion"| SP2 --> OK2["App B open,
no login shown"] ``` ## SP-initiated vs. IdP-initiated | | SP-initiated | IdP-initiated | | --- | --- | --- | | Starts at | The app ("Sign in with SSO") | The IdP dashboard tile | | Request | SP issues an authentication request | None — assertion arrives unsolicited | | Reply binding | Assertion answers a specific request | No request to match against | | Security posture | The default — replay checks anchor to the request | Historically weaker; unsolicited assertions invite injection | | Support it? | Always | Only where the IdP requires it, with extra validation | 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](https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html) specifies the two profiles; the practical rule is in the table's last row. ## SAML vs. OIDC | | SAML 2.0 | OpenID Connect | | --- | --- | --- | | Era & format | 2005 · XML assertions | 2014 · [JWTs](/glossary/json-web-token-jwt/) on [OAuth 2.0](/glossary/oauth-2-social-login/) | | Transport | Browser POST/redirect bindings | REST + redirects | | Fits | Enterprise web apps, legacy IdPs | Mobile, SPAs, APIs — anything current | | Developer experience | Verbose, brittle, library-dependent | Readable tokens, standard flows | | Verdict | Support it because customers' IdPs speak it | Choose it for everything new | And the triangle that untangles the acronyms, once: **SAML and OIDC do authentication for SSO; [OAuth 2.0 alone is authorization](/glossary/authentication-vs-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](/glossary/session-management/), 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](/glossary/multi-factor-authentication-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 | Situation | Lean | | --- | --- | | Selling to enterprises | Yes — OIDC + SAML; it gates deals | | Internal tools behind one workforce IdP | Yes — centralize MFA and offboarding | | Consumer app | [Social login](/glossary/oauth-2-social-login/) — same machinery, consumer IdPs | | One app, small team | Sessions + MFA suffice; revisit at app number three | | High-assurance apps behind SSO | Add step-up auth — don't ride the blanket session | | Choosing a protocol today | OIDC first; SAML for the customers who require it | ## 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](/glossary/oauth-2-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.