Single Sign-on

New
adopt
First Added:May 17, 2026

Single Sign-on

Single sign-on (SSO) lets a user authenticate once with an identity provider (IdP) and access multiple applications without separate passwords per app. We adopt SSO for B2B Software as a Service and internal tools: it is Enterprise Ready table stakes, pairs with RBAC, and reduces password sprawl when implemented with standard protocols.

Blurb

Single sign-on (SSO) is an authentication scheme that allows a user to log in with a single ID to any of several related, yet independent, software systems.

Summary

Protocols (prefer standards):

ProtocolTypical use
OIDCModern SaaS, SPAs, mobile; built on OAuth 2.0
SAML 2.0Enterprise IdP connections (Okta, Entra ID, Google Workspace)
OAuth 2.0Delegated API access (not full SSO by itself)

When adopt applies:

  • Selling to enterprises that mandate their IdP (Enterprise Ready)
  • Workforce apps (dashboards, ArgoCD, Boundary (Hashicorp)) via corporate OIDC
  • Customer orgs with “login with your company’s SSO” on your product

Implementation paths:

ApproachGarden notes
Embedded IdPAuth0 / FrontEgg (assess) for product login + SAML/OIDC connections
Cloud-nativeCognito, Entra, Google Identity for simpler estates
Self-hostedKeycloak-class when residency or control demands it

Security expectations: MFA at the IdP, short session lifetimes, audit logs, and Access on Demand for privileged production access (SSO is not the same as standing admin).

Details

TopicNotes
SP vs IdPYour app is the service provider; customer brings the IdP metadata
JIT provisioningMap SAML/OIDC claims to users and RBAC roles
SCIMOptional next step for directory sync (not required for basic SSO)
TestingStaging IdP connection per customer; document clock skew and cert expiry
Break-glassLocal emergency accounts outside SSO, vaulted and audited

Garden pattern: adopt SSO on every customer-facing SaaS before enterprise sales; assess which IdP product fits. Do not build custom password stores for B2B if SSO is on the roadmap.

References