Single Sign-On (SSO)
Practice this topic in a realistic system design interview
Large companies run dozens of internal and SaaS tools such as Salesforce, Workday, and Jira. Asking users to keep a separate password for each tool is painful for users and risky for security. Single Sign-On (SSO) fixes that by letting users sign in through one trusted identity system and then access many applications.
In a company, this usually means signing in through a corporate Identity Provider such as Okta, Microsoft Entra ID, or Google Workspace. Applications such as Salesforce and AWS trust that provider instead of running their own password systems.
SSO is not one shared session across every application. It is a trust pattern: the IdP signs the user in, the application checks the signed identity data from the IdP, and the application creates its own local session. The application still decides what the user is allowed to do inside that app.
This chapter covers how SSO works and the protocols behind it.