How it typically works?
- User authentication: the user logs in once through an identity provider (IdP).
- Token issuance: the IdP generates a secure token that confirms the user’s identity.
- Application access: when the user tries to access an application, the token is validated by the service provider (SP).
- Session management: as long as the session remains valid, the user can move between applications without re-entering credentials.
- Re-authentication: once the session expires or security policies require it, the user must authenticate again.
SSO relies on trust relationships between the identity provider and service providers, often based on security protocols such as SAML or OAuth.
Common techniques
- SAML (Security Assertion Markup Language): an XML-based protocol often used in enterprise SSO for web applications.
- OAuth 2.0: widely used for consumer-facing applications such as Google or Facebook logins.
- OpenID Connect (OIDC): built on OAuth, it provides authentication and identity data exchange.
- Kerberos-based SSO: common in Windows Active Directory environments.
- Cloud-based SSO: platforms like Okta or Azure AD extend SSO capabilities to SaaS applications.
- Federated SSO: enables identity federation across organizational boundaries.
Impact
SSO has significant benefits for both users and security teams.
For users, it:
- Reduces the number of passwords they must remember.
- Streamlines access to applications, improving productivity.
- Encourages stronger password practices since fewer credentials are required.
For organizations, it:
- Centralizes authentication, making it easier to enforce policies such as multi-factor authentication.
- Improves auditing and monitoring by consolidating login events.
- Reduces helpdesk costs associated with password resets.
However, SSO also introduces risks. If an attacker compromises a user’s SSO credentials, they may gain access to multiple applications at once. For this reason, SSO is often paired with MFA and strong identity governance.