Single sign-on (SSO) is an authentication arrangement in which a person proves who they are once, to a central service called an identity provider, and then gains access to many separate applications without typing a password into each. The applications never see the password. They receive a signed statement from the identity provider saying that a named user has just authenticated. It exists because people with dozens of accounts reuse weak passwords, and companies need one switch to revoke a leaver's access everywhere.

An agency employee who opens Slack, Salesforce and a reporting dashboard through a company portal is using enterprise SSO. A consumer who taps "Continue with Google" at a retailer's checkout is using social login, a consumer variant built on the same standards.

How single sign-on works

Every SSO exchange involves three parties: the user, the service provider (SP), which is the application and is called the relying party in some standards, and the identity provider (IdP), which holds the credentials and vouches for the user. The SP and IdP are configured in advance to trust each other by exchanging metadata, including public keys.

A typical login under SAML (Security Assertion Markup Language) 2.0, the dominant enterprise standard, runs in six steps:

  1. The user requests a page in the application, for example a CRM.
  2. The application has no session for that user, so it redirects the browser to the identity provider with an authentication request.
  3. The identity provider checks whether it already has a session for the user. If not, it asks for a password, a passkey or another factor.
  4. The identity provider builds an assertion, a signed XML document stating the user's identifier, the time of authentication, the intended audience and optional attributes such as role.
  5. The browser carries the assertion back to the application, usually through an automatically submitted form.
  6. The application verifies the signature, audience and validity window, then creates its own session.

The second application the user visits repeats steps 1 to 6, but step 3 is skipped because the identity provider's session already exists. That skipped step is the "single" in single sign-on.

OpenID Connect (OIDC) performs the same job with JSON (JavaScript Object Notation) instead of XML. It is an identity layer built on OAuth 2.0, the authorisation framework covered in PPC Land's explainer on OAuth. The identity provider returns an ID token, a signed JSON Web Token (JWT) containing claims such as "iss" (issuer), "aud" (the application it was issued to), "exp" (expiry) and "sub" (subject), a stable identifier for the user. OIDC underpins Sign in with Google, Sign in with Apple and Facebook Login's Limited Login mode.

Inside corporate networks, Kerberos, developed at the Massachusetts Institute of Technology (MIT), issues encrypted "tickets" from a central key distribution centre. Microsoft made it the default domain authentication protocol in Windows 2000.

Sessions, tokens and provisioning

SSO creates several sessions that expire on different clocks: one at the identity provider, one per application, and tokens with their own lifetimes. SAML assertions are normally valid for minutes. Microsoft assigns Entra ID access tokens a default lifetime chosen randomly between 60 and 90 minutes, according to its documentation, while Google Workspace sets a default web session length of 14 days for administrators to shorten.

Logging out is harder. Single logout (SLO) asks every application to end its session when the user leaves the identity provider, but support is inconsistent.

Access also has to be created and removed. SSO handles authentication, while provisioning handles accounts. SCIM (System for Cross-domain Identity Management) 2.0, published by the Internet Engineering Task Force (IETF) as RFC 7643 and RFC 7644 in September 2015, lets an identity provider create, update and deactivate user accounts in connected applications automatically. Without it, a departed employee may lose SSO access but keep a dormant account or API key inside the application.

Who operates it

Inside customer organisations, IT and identity teams choose the identity provider, register each application, map groups to roles and set authentication policy. Large vendors include Okta, which counted about 17,000 corporate customers in October 2023, according to TechCrunch, Microsoft with Entra ID (renamed from Azure Active Directory on July 11, 2023), Google Workspace and Ping Identity.

Software vendors implement the service provider role and decide which plans include it. In social login, Google, Apple or Meta is the identity provider and the publisher, retailer or app is the relying party.

Origin and evolution

Kerberos came out of MIT's Project Athena in the 1980s; Version 5 was published as RFC 1510 in September 1993. Web SSO needed a way to pass identity between domains, which cookies could not do. The OASIS Security Services Technical Committee met for the first time in January 2001 and produced SAML 1.0, adopted as an OASIS standard in November 2002. SAML 1.1 followed in September 2003. SAML 2.0, which drew on work from the Liberty Alliance and the university Shibboleth project, became an OASIS standard in March 2005 and remains the version most enterprises run.

Consumer login took a different route. Facebook launched Facebook Connect in 2008, and OAuth 2.0 was published as RFC 6749 in October 2012. The OpenID Foundation released the final OpenID Connect specification on February 26, 2014, and the core specifications became ISO/IEC standards in 2024, according to the foundation. Apple introduced Sign in with Apple at its developer conference on June 3, 2019, with a relay email option that hides the user's real address from the app.

Browser privacy changes forced a further adjustment. Federated logins once relied on third-party cookies, so Google began moving Sign in with Google to FedCM (Federated Credential Management), a browser-mediated API, from April 2024, as PPC Land reported in February 2024.

Why it matters for marketers

Access to ad platforms is the first concern, since agencies manage many client accounts whose logins are valuable to criminals. Google's decision to require passkeys for sensitive actions in Google Ads from July 15, 2026, such as changing user access, applies even when an organisation already uses Okta for SSO: the SSO layer handles the initial login, but Google demands its own passkey. PPC Land's passkey explainer describes the distinction as SSO deciding which systems a person can reach and a passkey deciding how identity is proved.

Social login is the second concern, because it produces authenticated users. Each login creates an addressable identity for first-party audiences, measurement and match rates. Meta moved a one-tap Facebook Login prompt into open beta on August 27, 2026.

The identifiers themselves can shift. When Google let US users change their Gmail usernames from March 31, 2026, platforms that keyed accounts on email address rather than the "sub" claim risked duplicate accounts. Apple is moving new Sign in with Apple relay addresses to a new private.icloud.com domain, which affects CRM validation rules.

Limitations and disputes

The main structural criticism is concentration. An identity provider becomes a single point of failure: if it is compromised, every connected application is exposed. In October 2023, attackers breached Okta's customer support system and took files containing session tokens, which were then used against 1Password, Cloudflare and BeyondTrust, according to TechCrunch. About 1% of Okta customers were affected. In 2023 a China-linked group, Storm-0558, used a stolen Microsoft signing key to forge tokens and read government email.

Token theft bypasses SSO's protections without breaking them. Adversary-in-the-middle phishing kits relay real login pages and keep the resulting session cookie, the technique behind session hijacking. An analytics engineer described being phished through a Google ad for Google Cloud Console in October 2026, with a lookalike domain relaying Google's real sign-in. Phishing-resistant methods such as passkeys, and session binding such as Chrome's Device Bound Session Credentials, are the industry's main responses.

Pricing is the most public dispute. Many software vendors offer SSO only on enterprise tiers, a premium critics call the SSO tax. 1Password cited HubSpot in June 2024: $15 a month for Starter against $1,500 for Enterprise, which included SSO. The Cybersecurity and Infrastructure Security Agency (CISA) published research in June 2024 on barriers to SSO adoption by small and medium-sized businesses and argued that "consumers should not need to pay premium pricing, hidden surcharges, or additional fees for basic security hygiene." Vendors argue enterprise tiers bundle support and audit features that cost money to build.

On the consumer side, social login gives identity providers a record of sites visited, and gives relying parties a durable email identifier that identity resolution firms have used for tracking.

Multi-factor authentication (MFA) requires more than one proof of identity at login. SSO decides how often that login happens, and most deployments enforce MFA at the identity provider.

OAuth grants an application permission to act on an account: authorisation, not authentication. Consumer SSO usually runs over OpenID Connect, which adds identity to OAuth.

Federated identity is the broader trust arrangement between organisations that lets one domain accept another's identities. SSO is its user-facing result. A password manager stores separate passwords for each site and fills them in, so each application still holds its own credential.

Recent developments

On August 21, 2026, Microsoft disclosed a maximum-severity flaw in Entra ID, CVE-2026-69836, rated 10 out of 10, according to Cybersecurity Dive, and later said it was "fully mitigated." The W3C published WebAuthn Level 3 as a Recommendation on August 25, 2026, allowing one passkey to cover at least five related domains.

On October 19, 2026, WebKit explained that Safari 27 blocks identity resolution services that convert login email addresses into tracking IDs. Apple's policy permits federated login through a visible provider the user chooses, but rejects invisible identification during login. Browser makers, not standards bodies, are now drawing the line between login as convenience and login as advertising signal.

Timeline

  • 1980s: Kerberos developed at MIT's Project Athena.
  • September 1993: Kerberos Version 5 published as RFC 1510.
  • February 2000: Windows 2000 ships with Kerberos as its default domain authentication protocol.
  • January 2001: OASIS Security Services Technical Committee holds its first meeting.
  • November 2002: SAML 1.0 adopted as an OASIS standard.
  • September 2003: SAML 1.1 approved.
  • March 2005: SAML 2.0 becomes an OASIS standard.
  • 2008: Facebook launches Facebook Connect.
  • October 2012: OAuth 2.0 published as RFC 6749.
  • February 26, 2014: OpenID Connect 1.0 final specification released.
  • September 2015: SCIM 2.0 published as RFC 7643 and RFC 7644.
  • June 3, 2019: Apple announces Sign in with Apple.
  • January 2021: Meta introduces Limited Login built on OpenID Connect.
  • May 5, 2022: Apple, Google and Microsoft commit to passkey support.
  • July 11, 2023: Microsoft renames Azure Active Directory as Microsoft Entra ID.
  • October 2023: Okta support system breach exposes customer session tokens.
  • April 2024: Google begins migrating Sign in with Google to FedCM in Chrome.
  • June 2024: CISA publishes research on barriers to SSO adoption for small and medium-sized businesses.
  • October 2024: OpenID Connect specifications published as ISO/IEC standards; OpenID Foundation working group on enterprise identity interoperability (IPSIE) announced.
  • March 31, 2026: Google lets US users change Gmail usernames.
  • July 15, 2026: Google Ads requires passkeys for sensitive actions.
  • August 21, 2026: Microsoft discloses CVE-2026-69836 in Entra ID.
  • August 25, 2026: W3C publishes WebAuthn Level 3 as a Recommendation.
  • August 27, 2026: Meta moves one-tap Facebook Login into open beta.
  • October 19, 2026: WebKit explains Safari 27's block on identity resolution services.

Summary

Who: Identity providers such as Okta, Microsoft Entra ID, Google and Ping Identity authenticate users; software vendors act as service providers; corporate IT and identity teams configure the connections. On the consumer web, Google, Apple and Meta act as identity providers for publishers, retailers and apps.

What: Single sign-on is an arrangement in which one authentication with a trusted identity provider grants access to many applications, which receive signed SAML assertions, OpenID Connect ID tokens or Kerberos tickets instead of passwords.

When: Kerberos dates from the 1980s, SAML 1.0 from November 2002, SAML 2.0 from March 2005 and OpenID Connect from February 26, 2014. In 2026, passkey requirements, FedCM, WebAuthn Level 3 and Safari 27's identity block are reshaping how logins are proved and used.

Where: Inside corporate networks and cloud workspaces, across software-as-a-service applications, on ad platform and agency tools, and on consumer websites and apps that offer social login buttons.

Why: SSO reduces password reuse and lets organisations grant and revoke access centrally. For marketers it governs who can touch client ad accounts, and social login produces the authenticated identities that audience building and measurement increasingly depend on. Its costs are concentration risk, token theft and the pricing premium known as the SSO tax.