Single Sign-On (SSO): One Login, Many Apps

WHY IT EXISTS As companies adopt more software-as-a-service (SaaS) tools, employees accumulate dozens of separate logins. This creates password fatigue, encourages insecure practices like password reuse, and makes it a nightmare for IT to manage access and deprovision users. SSO was created to solve this security and usability mess by centralizing authentication.

THE MENTAL MODEL Think of SSO like a passport for your digital workspace. You present your passport once to a central authority, the Identity Provider (IdP). The IdP verifies who you are and gives you a stamp (an authentication token). You can then show this trusted stamp to various other services (Service Providers like Salesforce or Slack) to gain entry, without having to prove your identity to each one individually.

HOW IT WORKS A typical SSO flow involves three parties: the user, the Service Provider (SP, the app you want to use), and the Identity Provider (IdP, the central login system). First, the user tries to access the SP. The SP, seeing the user is not authenticated, redirects them to the IdP. The user enters their credentials (e.g., username, password, MFA) into the IdP's login page. Once authenticated, the IdP sends a cryptographically signed assertion back to the user's browser, which then passes it to the SP. The SP verifies the signature on the assertion, confirms the user is legitimate, and grants access.

WHEN TO USE IT SSO is standard in corporate environments to manage employee access to a suite of internal and third-party applications. It's also used in consumer applications that offer social logins like "Sign in with Google" or "Sign in with Facebook." Use it whenever you need to provide a seamless user experience across multiple independent systems while maintaining centralized control over identity and access policies.

WHEN NOT TO USE IT For a single, standalone application, the complexity of setting up and maintaining an SSO infrastructure can be overkill. It also introduces a critical dependency; if your IdP is unavailable, no one can log into any of the connected applications. For extremely high-security, air-gapped systems, you might prefer isolated, explicit authentication for each access attempt.

ONE CANONICAL EXAMPLE An employee logs into their company laptop using their corporate credentials. This authenticates them with the company's IdP (like Azure Active Directory or Okta). Throughout the day, they open Salesforce, Confluence, and their HR portal. Because all these services are configured to trust the company's IdP, the employee is never prompted for another password and gains immediate access.