cybersecurity authentication

Single Sign-On (SSO)

sso authentication identity saml oidc
Plain English

SSO is a hotel key card that opens every door in the building. You check in once at the front desk (log in with your company credentials), and that one key card gets you into your room, the gym, the pool, and the business center without checking in separately at each one. In IT, you log into your company’s identity provider once, and that grants access to Slack, GitHub, AWS, Salesforce, and everything else, all without typing your password again.

Technical Definition

Single Sign-On (SSO) is an authentication scheme where a central Identity Provider (IdP) authenticates a user once and issues assertions that Service Providers (SPs) accept in place of credentials.

The two dominant SSO protocols:

SAML 2.0 (Security Assertion Markup Language):

  • XML-based, designed for enterprise web applications
  • IdP issues a cryptographically signed XML assertion after authentication
  • SP validates the assertion signature using the IdP’s public certificate
  • Common flow: SP-initiated (redirect to IdP, come back with assertion) or IdP-initiated (IdP pushes users directly)
  • Used by: Okta, Azure AD, Google Workspace for enterprise integrations

OpenID Connect (OIDC):

  • JSON/JWT-based layer on top of OAuth 2.0
  • IdP issues an ID token (JWT) after the OAuth authorization code flow
  • SP validates the JWT signature using the IdP’s JWKS endpoint
  • Simpler to implement than SAML; native fit for REST APIs and mobile apps
  • Used by: Auth0, Clerk, Google, GitHub OAuth apps

SSO trust model:

  1. SP and IdP pre-register with each other (metadata exchange): SP shares its ACS URL; IdP shares its public signing certificate
  2. User attempts to access SP, is redirected to IdP with a SAMLRequest or authorization request
  3. IdP authenticates the user (may prompt for MFA)
  4. IdP redirects back to SP with a signed assertion or authorization code
  5. SP validates the assertion, creates a local session, and grants access

Security considerations:

  • SAML assertions have an NotOnOrAfter timestamp; replay attacks are defeated by enforcing this
  • OIDC ID tokens have exp; validate it before trusting claims
  • The IdP is a single point of failure: IdP downtime means no access to any SP
  • Enforce MFA at the IdP level so all SSO-integrated apps inherit it automatically

SAML assertion structure and OIDC token flow 

<!-- Simplified SAML 2.0 assertion from IdP to SP -->
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  IssueInstant="2026-04-21T10:00:00Z">
  <saml:Issuer>https://idp.example.com</saml:Issuer>
  <saml:Conditions
    NotBefore="2026-04-21T09:59:00Z"
    NotOnOrAfter="2026-04-21T10:05:00Z">
    <saml:AudienceRestriction>
      <saml:Audience>https://app.example.com</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <saml:AttributeStatement>
    <saml:Attribute Name="email">
      <saml:AttributeValue>user@example.com</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute Name="groups">
      <saml:AttributeValue>engineering</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
  <!-- ds:Signature validates the assertion wasn't tampered with -->
</saml:Assertion>
# OIDC: exchange authorization code for tokens
$ curl -X POST https://idp.example.com/oauth2/token \
  -d "grant_type=authorization_code" \
  -d "code=AUTH_CODE_FROM_REDIRECT" \
  -d "redirect_uri=https://app.example.com/callback" \
  -d "client_id=app_client_id" \
  -d "client_secret=$CLIENT_SECRET"

# Response includes ID token (JWT with user identity)
{
  "access_token": "eyJhbGci...",
  "id_token": "eyJhbGci...",   # Contains sub, email, name claims
  "expires_in": 3600,
  "token_type": "Bearer"
}

# Fetch IdP's public keys for ID token verification
$ curl https://idp.example.com/.well-known/jwks.json
In the Wild

Okta and Azure Active Directory (now Entra ID) dominate enterprise SSO. Google Workspace acts as an IdP for many organizations, letting employees log into third-party tools with their Google account. From a security standpoint, SSO is a double-edged sword: it reduces password fatigue and enables centralized MFA enforcement, but it means a compromised IdP credential grants access to everything. This is why phishing-resistant MFA (hardware security keys, passkeys) at the IdP is non-negotiable in high-security environments. SSO is often paired with SCIM (System for Cross-domain Identity Management) for automated user provisioning and de-provisioning: when an employee is terminated in the HR system, SCIM automatically removes their accounts from all SSO-connected applications within minutes.

← Back to Dictionary