Single sign-on (SSO) is an authentication method that lets a user log in once, through a central identity provider, and gain access to every connected application without re-entering credentials. A developer at a mid-size engineering org might touch GitHub, Jira, AWS, Datadog, and a CI/CD platform before 10 a.m.; with SSO, one authentication event at Okta, Microsoft Entra ID, or Ping Identity issues a signed token that each of those systems trusts. Without it, that same developer juggles five separate passwords, five reset flows, and five places where a single leaked credential hands an attacker a foothold. SSO collapses that sprawl into one login screen and one policy surface, which is why SAML- or OIDC-based SSO shows up as a control in nearly every SOC 2 Type II report and ISO 27001 audit security teams review today. It is also, increasingly, a single point of failure attackers target directly rather than attacking each downstream app one at a time.
What is single sign-on (SSO), technically?
Single sign-on is an authentication architecture in which one trusted identity provider (IdP) authenticates a user once and issues a cryptographically signed assertion or token that multiple separate service providers (SPs) accept as proof of identity. The user never enters a password directly into the application they're trying to reach — instead, the application redirects them to the IdP, the IdP does the verifying, and a signed artifact travels back confirming who the user is and, often, what they're allowed to do. A familiar consumer example is "Sign in with Google": logging into Google once grants access to Gmail, Drive, and Calendar, and any third-party app offering a "Sign in with Google" button is relying on the exact same underlying protocol (OpenID Connect) rather than building its own password system.
How does an SSO login flow actually work?
An SSO login flow works by redirecting an unauthenticated user from the application to the identity provider, verifying credentials there, and returning a signed token the application validates before granting access. In a typical SAML flow: (1) a user hits a protected URL on the service provider, (2) the SP redirects to the IdP with an authentication request, (3) the IdP prompts for credentials (and MFA, if configured), (4) on success the IdP builds a signed XML assertion containing the user's identity and attributes, (5) the browser POSTs that assertion back to the SP's assertion consumer service endpoint, and (6) the SP verifies the signature against the IdP's public certificate and creates a local session. OpenID Connect follows a similar redirect pattern but exchanges a signed JSON Web Token (JWT) instead of an XML assertion, with standard claims like iss (issuer), sub (subject), aud (audience), and exp (expiration) that the relying application checks before trusting the token.
What's the difference between SSO, MFA, and federated identity?
SSO, MFA, and federated identity are three distinct but complementary controls that get conflated constantly. SSO reduces how many times a user logs in; multi-factor authentication (MFA) strengthens each login by requiring a second proof of identity, such as a push notification or hardware key, alongside the password; and federated identity extends trust across organizational boundaries, letting Company A's applications accept identity assertions issued by Company B's identity provider. A concrete example: a contractor from a staffing firm logging into a client's Jira instance using their staffing firm's Okta credentials is federation. That same contractor being prompted for a Duo push after entering their password is MFA. Neither one is SSO by itself — SSO is specifically the "log in once, use everywhere" property, and it's entirely possible (and common) to have SSO without MFA, which is exactly the gap that made several 2022–2023 identity breaches possible.
Which protocols and standards power modern SSO?
Modern SSO runs on four standards published between 2005 and 2015: SAML 2.0 (ratified by OASIS in March 2005) for XML-based assertions, OAuth 2.0 (RFC 6749, October 2012) for delegated authorization, OpenID Connect 1.0 (finalized February 2014) for layering identity on top of OAuth, and SCIM 2.0 (RFC 7643/7644, September 2015) for automating account provisioning and deprovisioning between the IdP and downstream apps. SAML still dominates legacy enterprise integrations — think on-prem Active Directory Federation Services talking to an internal HR portal — while OIDC has become the default for cloud-native apps and consumer-facing "social login" buttons from Google, Microsoft, and Apple, largely because JWTs are lighter weight and easier to parse in JavaScript than XML assertions. SCIM matters more than it gets credit for: without it, offboarding an employee from the IdP doesn't actually revoke their access to the 40+ SaaS tools they were provisioned into, it just removes the front door while leaving every side door open.
What security risks does SSO introduce, and how have attackers exploited it?
SSO risk concentrates identity into a single trusted authority, so compromising the identity provider or stealing a live session token gives an attacker access to every downstream application that trusts it — turning one breach into dozens. The "0ktapus" campaign, documented by Group-IB in August 2022, used SMS phishing pages that mimicked Okta login screens to harvest roughly 9,931 credentials and MFA codes from employees at 136 organizations, including Twilio, Cloudflare, and DoorDash, then pivoted through those stolen SSO sessions into internal systems. A year later, Okta itself disclosed on October 20, 2023 that an attacker had used a stolen credential to access its customer support case management system and view files — including session tokens — uploaded by 134 of its customers; that access was later linked to follow-on compromises at BeyondTrust and Cloudflare. Beyond credential theft, "Golden SAML" attacks forge signed SAML assertions outright if an attacker steals the IdP's private signing key, bypassing the login process entirely, and misconfigured trust relationships (an SP accepting assertions from the wrong issuer, or skipping signature validation) have shown up repeatedly in bug bounty reports for SAML libraries like ruby-saml and python3-saml. The pattern across all of these: SSO doesn't eliminate identity risk, it relocates it to a smaller number of much higher-value targets.
How Safeguard Helps
Safeguard treats SSO and identity-adjacent code paths as high-value attack surface, not just another dependency. Griffin AI, Safeguard's triage engine, prioritizes CVEs in SAML, OAuth, and OIDC libraries — like XML signature wrapping bugs in ruby-saml or JWT validation flaws — based on real exploitability rather than raw CVSS score. Reachability analysis confirms whether your codebase actually calls the vulnerable assertion-parsing or token-verification function before a fix gets prioritized, cutting through noise on libraries that are present but never invoked. Safeguard generates and ingests SBOMs so every service that touches identity tokens is tracked continuously, and where a patch exists, Safeguard opens an auto-fix pull request that upgrades the vulnerable identity library and lets your team merge with confidence instead of hand-patching under pressure after the next Okta-adjacent headline.