Catalog
concept#Security#Integration#Architecture#Platform

Single Sign-on (SSO)

SSO enables centralized authentication across multiple applications, reducing login friction and simplifying access control.

Single sign-on (SSO) enables users to authenticate once and access multiple independent systems or applications.
Established
Medium

Classification

  • Medium
  • Organizational
  • Architectural
  • Intermediate

Technical context

Identity providers (Keycloak, Auth0, Azure AD)Directory services (LDAP, Active Directory)Application gateways and proxies

Principles & goals

Centralized identity managementMinimize local credentialsClear delegation of authentication responsibility
Build
Enterprise, Domain

Use cases & scenarios

Compromises

  • Single point of failure in authentication service
  • Misconfigured token or session management
  • Insufficient authorization boundaries in federation
  • Use established protocols (OIDC, SAML) rather than proprietary solutions.
  • Implement centralized MFA policies.
  • Perform regular audits and token lifecycle reviews.

I/O & resources

  • Directory service (e.g., LDAP, AD)
  • Identity provider with SSO support
  • Application-side integration (SAML/OIDC/OAuth)
  • Centralized authentication and session management
  • Consistent access controls and audit logs
  • Reduced number of local passwords

Description

Single sign-on (SSO) enables users to authenticate once and access multiple independent systems or applications. It reduces password fatigue, simplifies user administration, and enables centralized access control. SSO relies on protocols like SAML, OAuth and OpenID Connect and requires an identity provider and governance.

✔

  • Reduced administrative overhead
  • Improved user experience with fewer logins
  • Centralized audit and access control

✖

  • Dependency on identity provider availability
  • Complex integration for legacy systems
  • Requires coordination across teams and applications

  • Number of successful SSO logins

    Measures usage and adoption of the SSO system.

  • IdP MTTR

    Time to recover after identity provider outage.

  • Number of failed token validations

    Indicator of configuration or integration issues.

Enterprise-wide SSO deployment

A multinational company deploys SSO using OpenID Connect and a central IdP to improve user experience and compliance.

Customer access with social login

A portal allows customers to sign in via external identity providers (e.g., Google), delegating authentication and reducing password maintenance.

Integrating legacy app via proxy

A legacy application is connected to enterprise SSO via a proxy, avoiding major internal code changes.

1

Evaluate current authentication landscape and protocol support.

2

Select an identity provider and define policies.

3

Incrementally integrate applications and set up monitoring.

⚠️ Technical debt & bottlenecks

  • Temporary adapters for legacy systems that should be replaced later.
  • Legacy token handling implementations lacking RS256 support.
  • Insufficiently documented integration paths between services.
Identity provider capacityNetwork latency with external providersLegacy application compatibility
  • Deploying an IdP without HA, causing outages to affect the entire organization.
  • Federating overly privileged roles without proper mapping.
  • Using SSO for authorization instead of separating authn and authz properly.
  • Underestimating required governance for identity lifecycles.
  • Lack of tests for logout propagation across services.
  • Unclear responsibilities between IdP and application teams.
Identity and access management skillsKnowledge of SAML, OAuth and OpenID ConnectOperational knowledge for high availability and security
Interoperability between applicationsScalability and availability of the IdPSecure token and session management
  • • Adoption requires organizational coordination
  • • Regulatory requirements for identity data
  • • Technical limitations of non-compatible applications