Single Sign-On (SSO)

Security Assertion Markup Language 2.0 is an XML-based open standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). It enables web-based single sign-on (SSO) and is widely used in enterprise environments.

• Key Components: Assertions (authentication, attribute, authorization decisions), Protocols (AuthnRequest, Response), Bindings (HTTP POST, Redirect).
• Flow: The user accesses the SP, which generates a SAML AuthnRequest and redirects the user to the IdP. After authentication, the IdP creates a SAML Response containing an Assertion, which is posted back to the SP's Assertion Consumer Service (ACS) URL for validation.
• Use Case: Classic enterprise SSO for internal applications like HR systems, CRMs, and legacy web portals.

OpenID Connect is a modern, JSON-based identity layer built on top of the OAuth 2.0 authorization framework. It allows 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.

• Key Components: ID Token (a JWT), UserInfo Endpoint, Standard Claims (sub, name, email).
• Flow: Extends the OAuth 2.0 Authorization Code flow. After user consent, the client receives an Authorization Code, exchanges it for an ID Token and Access Token. The ID Token contains verifiable user identity claims.
• Use Case: Modern web and mobile applications (B2C, SaaS), API access where user identity and lightweight profile data are required. It is the foundation for "Login with Google/Facebook" and many customer-facing apps.

OAuth 2.0 is an authorization framework, not an authentication protocol, but it is critical to modern SSO. It enables a third-party application to obtain limited access to a user's resources on an HTTP service, without sharing the user's credentials.

• Core Concept: Delegated Access. A user (resource owner) grants an application (client) permission to access specific resources (scopes) on their behalf from a resource server.
• Key Grants for SSO Context:
  • Authorization Code Flow: The most secure and common flow for web apps, used by OIDC.
  • Proof Key for Code Exchange (PKCE): Essential extension for mobile and single-page apps to prevent code interception attacks.
  • Client Credentials Flow: For machine-to-machine (M2M) communication where no user is present.
• Role in SSO: Provides the secure token issuance and validation mechanism that OIDC layers identity on top of.

WS-Federation is a SOAP/WS-Trust-based identity federation specification, part of the larger WS-* security standards. It defines mechanisms for allowing different security realms to broker information on identities, identity attributes, and authentication.

• Key Components: Security Token Service (STS), Request Security Token (RST), Request Security Token Response (RSTR).
• Flow: A user accesses a relying party (RP). The RP redirects the user to an STS. The user authenticates, and the STS issues a security token (often a SAML 1.1 token). This token is presented to the RP for access.
• Use Case: Primarily found in legacy Microsoft ecosystems (e.g., Active Directory Federation Services for SharePoint, older .NET applications). It has largely been superseded by SAML 2.0 and OIDC for most new implementations.

JSON Web Token (JWT) is the de facto token format for modern identity protocols. It is a compact, URL-safe token (RFC 7519) that encodes a set of claims as a JSON object, which can be digitally signed (JWS) or encrypted (JWE).

• Structure: Header.Payload.Signature
  • Header: Specifies the token type (JWT) and the signing algorithm (e.g., RS256).
  • Payload: Contains the claims (e.g., iss (issuer), sub (subject), exp (expiration), custom data).
  • Signature: Created by signing the encoded header and payload with a secret or private key to verify integrity.
• Usage:
  • ID Token in OIDC: A signed JWT containing user identity claims.
  • Access Token: Often a JWT (a "JWT access token") allowing the resource server to validate it locally without a network call.
• Validation: Resource servers validate the JWT's signature (using the IdP's public key from a JWKS endpoint), expiry, issuer, and audience.

Choosing an SSO protocol depends on application architecture, security requirements, and ecosystem. Key decision factors include:

• Application Type:
  • Modern SPAs/Mobile Apps: OIDC with PKCE is the mandatory choice for its native browser/device support and security.
  • Traditional Enterprise Web Apps: SAML 2.0 remains strong due to deep enterprise IdP integration and maturity.
  • Machine-to-Machine (M2M): OAuth 2.0 Client Credentials Flow.
• Data Needs:
  • Need simple user identity and basic claims? Use OIDC.
  • Need rich, custom attribute exchange? SAML is more flexible.
• Security Profile:
  • FAPI (Financial-grade API): A high-security profile of OAuth 2.0/OIDC for banking and sensitive data.
  • mTLS-bound tokens: For high-assurance scenarios, combining OAuth with Mutual TLS for client authentication.
• Ecosystem: Microsoft Azure AD/Azure Entra ID supports SAML, OIDC, and WS-Fed. Many modern SaaS platforms prioritize OIDC.