Single Sign-On (SSO)

A mid-size company runs 50 internal tools. Slack, Jira, GitHub, Salesforce, AWS Console, a dozen homegrown apps. Every tool has its own login screen. Employees reuse the same password across a handful of them, write the rest on sticky notes, and call IT three times a week for resets. Gartner estimates that 20-50% of all IT help desk calls are password resets, costing about $70 per ticket.

When someone leaves the company, HR sends a list to IT. IT has to disable the person's account in each of those 50 tools. Inevitably, two or three get missed. The former employee still has access to GitHub and the AWS console three months later.

SSO eliminates this entire category of problems. One login at the start of the day, and that session carries the employee into every connected application. One account to disable on the last day, and every app goes dark at the same moment.

SSO has three participants: the user, the identity provider (IdP), and the service provider (SP, which is the application the user wants to reach).

The flow goes like this:

1. Employee opens app.company.com. The app has no idea who they are.
2. The app redirects the browser to the IdP (Okta, Azure AD, Google Workspace).
3. The IdP checks whether the user already has a valid session. If so, skip to step 5. If not, the IdP shows a login screen.
4. The user authenticates with the IdP. Password, MFA, hardware key, whatever the organization requires.
5. The IdP generates a signed assertion (SAML) or an ID token (OIDC) containing the user's identity, email, department, roles.
6. The browser carries that assertion back to app.company.com.
7. The app validates the signature, extracts the identity, creates a local session.
8. When the same user opens another-app.company.com, the redirect to the IdP happens again, but the IdP already has a session from step 4. No login prompt. The user is in.

That second login takes under 500ms from the user's perspective. They click the app and they are in.