Single sign-on (SSO) lets users authenticate once and access multiple applications without re-entering credentials for each app.
Why organizations adopt SSO
- reduce password fatigue and reset tickets,
- centralize policy controls (MFA, session timeout, device posture),
- speed up onboarding/offboarding across many apps.
SSO architecture in plain language
An identity provider (IdP) becomes the central login authority.
Applications (service providers) trust the IdP and accept its authentication proof (token/assertion) instead of collecting credentials directly.
Typical SSO login flow
- User opens an application.
- App redirects user to IdP login.
- IdP authenticates and enforces policy.
- IdP returns signed identity proof.
- App validates proof and starts session.
SSO protocols you will see
- SAML: common for enterprise browser SSO.
- OIDC: common for modern web/mobile ecosystems.
- OAuth 2.0: authorization framework (often paired with OIDC for authentication).
Security benefits
- fewer local app passwords to manage,
- consistent MFA enforcement,
- centralized anomaly detection and account controls.
Security risks if implemented poorly
- IdP outage or compromise can create broad blast radius,
- over-permissive role mapping can spread access errors,
- long-lived sessions can increase account takeover impact.
SSO rollout checklist
- Define role/attribute mapping per application.
- Enforce MFA and conditional access rules.
- Validate session timeout and re-authentication controls.
- Test user lifecycle events (join, role change, leave).
- Keep emergency admin access outside normal SSO path.
SSO and user experience
Well-implemented SSO improves UX and security at the same time.
Poorly implemented SSO often shifts friction to support and access recovery flows. Include recovery design from day one.
Related routes
Final take
SSO is an identity control plane decision, not just a login widget. The operational success comes from policy design, role hygiene, and rigorous rollout testing.