Single Sign-On (SSO)

SSO establishes a single, authoritative Identity Provider (IdP) that performs user authentication. This creates a unified security perimeter where login policies, password strength rules, and multi-factor authentication (MFA) are enforced consistently. Instead of credentials being stored and verified in dozens of individual applications, authentication logic is consolidated. This architecture is essential for enforcing enterprise-wide security standards and simplifying compliance audits.

By eliminating the need for separate passwords per application, SSO drastically reduces the attack surface for credential-based attacks like phishing and credential stuffing. Users only manage one set of strong credentials protected by MFA at the IdP. This minimizes the risk of weak, reused, or written-down passwords compromising enterprise systems. For security teams, it means fewer password-related help desk tickets and a more defensible identity perimeter.

SSO enables federated identity, allowing trust between the IdP and independent Service Providers (SPs). This is achieved through standardized protocols:

• SAML 2.0: An XML-based standard common in enterprise environments.
• OpenID Connect (OIDC): A modern, JSON-based identity layer built on OAuth 2.0, prevalent in web and mobile applications.
• WS-Federation: A Microsoft-developed protocol. These protocols allow the secure exchange of authentication assertions or ID tokens, conveying proof of login without transmitting the user's primary credentials to the application.

Users authenticate once at the IdP and gain seamless access to all connected applications without repeated logins. This eliminates password fatigue and reduces time wasted managing multiple accounts. The experience is often delivered via a central portal or dashboard. For new employees, automated provisioning (often via SCIM) can create application accounts instantly upon SSO login, accelerating onboarding. Session management at the IdP can also enable convenient features like "Remember Me" or conditional re-authentication for sensitive actions.

SSO provides a central point for critical security and governance functions:

• Instant Deprovisioning: Revoking access at the IdP immediately blocks access to all connected applications, a crucial control for offboarding.
• Granular Session Management: Enforce global session timeouts and inactivity policies.
• Centralized Auditing & Reporting: Generate unified logs of all authentication events and access attempts for compliance (e.g., SOX, HIPAA) and security monitoring.
• Risk-Based Authentication: Integrate with systems that analyze login context (location, device, behavior) to trigger step-up authentication (like MFA) for risky sessions.

SSO is not a standalone system; it integrates into a broader Identity and Access Management (IAM) strategy. It works in concert with:

• Provisioning Systems (e.g., SCIM): For automated user account lifecycle management.
• Directory Services (e.g., Active Directory, LDAP): As the primary source of user identities.
• Privileged Access Management (PAM): SSO can serve as a gateway to PAM systems for managing elevated access to critical infrastructure.
• API Access Management: Modern SSO/OIDC is used to secure machine-to-machine API communications using tokens like JWTs, extending secure access principles beyond human users to AI agents and microservices.

An XML-based open standard for exchanging authentication and authorization data between an Identity Provider (IdP) and a Service Provider (SP). It is a foundational protocol for enterprise web-based SSO.

• Key Role: Defines the structure for security "assertions" (statements about a user's identity).
• Common Flow: A user accesses an application (SP), which redirects them to their organization's IdP (like Okta or Azure AD). After authentication, the IdP sends a SAML assertion back to the SP, granting access.
• Use Case: Primarily used for browser-based access to enterprise SaaS applications.

A simple identity layer built on top of the OAuth 2.0 authorization framework. It enables clients to verify the identity of an end-user based on the authentication performed by an Authorization Server and to obtain basic profile information about the user.

• Modern Standard: Uses lightweight JSON Web Tokens (JWT) instead of XML, making it more suitable for modern web and mobile applications.
• Core Artifact: Returns an ID Token, a JWT containing verifiable claims about the user's identity.
• Use Case: Common in consumer-facing applications ("Sign in with Google") and modern API-driven architectures.

The industry-standard authorization framework (RFC 6749) that enables a third-party application to obtain limited access to a user's resources on an HTTP service. It is the foundation upon which OpenID Connect (OIDC) is built.

• Core Concept: Delegated Access. It allows users to grant an application access to their data on another service (e.g., a scheduling app accessing your Google Calendar) without sharing your password.
• Key Flows: Defines several grant types (Authorization Code, Client Credentials, etc.) for different application types (web, mobile, server).
• SSO Relationship: SSO systems like OIDC use OAuth 2.0 flows to securely obtain tokens that represent an authenticated user session.

A trusted system that creates, maintains, and manages digital identity information for users or systems (called principals) and provides authentication services to other applications (Service Providers) within a federated network.

• Central Authority: Acts as the single source of truth for user credentials and authentication. Examples include Okta, Microsoft Entra ID (Azure AD), Ping Identity, and Auth0.
• SSO Role: In an SSO flow, the IdP is the service that performs the primary user login. After successful authentication, it generates and signs a security token (like a SAML assertion or OIDC ID Token) asserting the user's identity to the requesting application.
• Key Functions: Manages user directories, enforces multi-factor authentication (MFA) policies, and handles password management.

A compact, URL-safe token format (RFC 7519) used to securely transmit claims between two parties as a JSON object. JWTs can be digitally signed (using a secret or a public/private key pair) or encrypted.

• Structure: Consists of three Base64Url-encoded parts separated by dots: Header.Payload.Signature.
• Payload: Contains the "claims," which are statements about an entity (typically the user) and additional metadata (like issuer and expiration).
• SSO Role: The primary token format for OpenID Connect. The ID Token is a JWT. It allows a Service Provider to verify the token's integrity and authenticity without querying the IdP for every request, enabling stateless session management.

A system architecture where the management of user identities and authentication is delegated to one or more external, trusted identity providers. It allows users from one security domain to access resources in another domain using a single set of credentials.

• Core Principle: Trust Relationships. The Service Provider trusts the Identity Provider to correctly authenticate users.
• Standards-Based: Enabled by protocols like SAML, OIDC, and WS-Federation.
• SSO Relationship: SSO is the primary user experience enabled by a federated identity model. Federation provides the technical and trust framework that makes cross-domain SSO possible, such as an employee using their corporate credentials to log into Salesforce or Workday.