Single Sign On

Single sign on, known as SSO, lets a person log in once and open many applications without typing a password again. Federation extends the same idea across organizations, so one trusted identity works in many separate systems.

The Theme Park Wristband Analogy

A theme park checks your ticket at the gate and fastens a wristband on your arm. Every ride accepts the wristband, and no ride asks for a new ticket. SSO behaves like that gate. The login page verifies you once, and every connected application trusts the result.

Why Organizations Use SSO

• Employees remember one strong password instead of twenty weak ones
• Help desks receive fewer password reset requests
• Security teams switch off one account to remove access everywhere
• Multi-factor authentication applies in one central place

Key Players in the Process

User

The person who wants to open an application.

Identity Provider

The trusted system that checks the password and issues proof of identity. Examples include Microsoft Entra ID, Okta, and Google Identity.

Service Provider

The application that accepts the proof and grants entry, such as a payroll tool or a cloud console.

How a Login Flows

 USER                SERVICE PROVIDER             IDENTITY PROVIDER
  |  1. Open app           |                              |
  |----------------------->|                              |
  |  2. Redirect to login  |                              |
  |<-----------------------|                              |
  |  3. Enter password + MFA ---------------------------->|
  |  4. Signed token  <-----------------------------------|
  |  5. Present token      |                              |
  |----------------------->|  6. Verify signature         |
  |  7. Access granted     |                              |
  |<-----------------------|                              |

The application never sees the password. It receives a signed token and checks the signature against the identity provider.

Common Standards

Standard	Purpose	Typical Use
SAML	Exchanges signed identity statements	Workplace web applications
OpenID Connect	Adds identity on top of OAuth	Modern web and mobile apps
OAuth 2.0	Grants limited access to resources	Letting one app read data in another

What Federation Adds

Federation connects identity systems from different organizations. A partner company's employees can open your project portal with their own company login. You never create or manage their accounts. The trust relationship does the work.

Partner Employee --> Partner Identity System ==trust==> Your Portal

Real-World Example: A University

A university runs email, a learning platform, a library system, and a cloud storage service. Students log in once each morning. A visiting researcher from another university signs in with her home credentials through federation. When a student graduates, the registrar disables one account and every service closes at once.

Security Risks to Manage

• One stolen SSO password opens many doors, so MFA is essential
• The identity provider becomes a high-value target and needs strong protection
• Long session lifetimes give attackers extra time after a stolen token
• Poorly checked tokens allow forged logins

Best Practices

• Require multi-factor authentication at the identity provider
• Set short session timeouts for sensitive applications
• Check token signatures, audience, and expiry on every request
• Log every sign-in and review unusual patterns
• Keep a backup administrator account stored safely offline

Key Takeaways

SSO simplifies life for users and administrators. Federation carries that trust across company boundaries. Strong MFA, short sessions, and careful token checks keep the convenience safe.