Single Sign-On
Add Single Sign-On (SSO) for all Identity Providers to your app with a single integration.
What is Single Sign-On?
Single Sign-On (SSO) is the most frequently asked for requirement by enterprise organizations looking to adopt new SaaS applications. SSO enables authentication via an organization’s Identity Provider (IdP), such as Google Workspace or Okta, as opposed to users or IT admins managing hundreds, if not thousands, of usernames and passwords. Facilitate greater security, easier account management, and accelerated application onboarding and adoption by adding SSO to your app.
If you’ve heard of SSO before, you’re probably thinking of it as a security feature, and that’s true; but where it really shines is through increased engagement. Making it easier to sign up for and sign into your product lowers friction for users, increases retention through smoother login flows, and helps you land those elusive enterprise deals (many enterprises can’t work with vendors who don’t support SSO).
How does SSO work?
The easiest way to understand SSO quickly is to think about your app’s authentication as a service. Most developers build the service themselves: you take care of creating usernames and passwords, adding them into a database, and checking credentials every time someone logs in. But in the same way that you skip building payments infrastructure and use Stripe, you can “outsource” your auth and have someone else do it; and that’s what SSO is.
The WorkOS SSO API is modeled to meet the OAuth 2.0 framework specification, abstracting away the underlying authentication handshakes between different IdPs. Check out the sequence of events below.
The WorkOS SSO API is authentication middleware and intentionally does not handle user database management for your application. This is by design, to minimize vendor lock-in for Developers.
Going deeper into how SSO works
If you’re integrating SSO into your app, you’re a service provider (SP). Your app is the service. The provider that you’re “outsourcing” identity to – like Okta or OneLogin – is called the identity provider (IDP). Simple enough, right? Where things start to get a bit more complex is when your app needs to communicate with identity providers to actually authenticate your users. SSO works with a communication protocol called SAML (Security Assertion Markup Language) that governs these phone lines.
SAML – and by extension, how you build and work with SSO – works through assertions.
Let’s walk through a typical SAML flow, starting with a user trying to sign in through your site.
SAML request from the SP
When a user navigates to your login page (to log in, of course), they’ll either enter their email or click a button that takes them to an IDP portal like Okta. Your app issues a SAML request (and a browser redirect) to the IDP: it’s basically saying “hey, this user wants to sign in, do me a favor and verify that I should let ‘em in.”
SAML assertion from the IDP
At the IDP, they’ll enter their full credentials, and deal with more extensive security measures like 2FA. Once they’ve successfully authenticated with the IDP, the IDP sends your app a response containing an assertion: this user is good to go, and you can let them in.
The flow we just outlined is called SP-initiated, because it started at your app, and you’re the service provider. There’s another way this can go down though: users can start at their IDP (like the Okta app directory), click on which app they want to sign into, and then authenticate and redirect. That’s called IDP-initiated.