SSO vs. OAuth: What's the Difference?
Intro
There's a lot of confusing jargon in the world of identity and access management (IAM). Developers often ask us to explain the differences between certain concepts. Here, I'll try to clear up a common source of confusion and explain SSO vs. OAuth.
In short, SSO and OAuth describe different kinds of technology concepts. If you're confused, it's probably less because we're comparing "apples and oranges" and more because we're comparing ... "canned goods and pomegranates."
Okay, well that wasn't likely very helpful. Sorry.
Let's start by looking at these ideas separately.
What is SSO?
SSO stands for "single sign-on." This is kind of a broad idea. When we say "single sign-on," we could be talking about a few different technologies. But they all share one key characteristic: a software application delegating authentication of its users to another piece of software.
If that doesn't mean anything to you, that's totally reasonable.
Let's think of an example.
Suppose there's a big company. We'll call it MegaCorp. A lot of people work at MegaCorp in all kinds of different functions: accounting, warehouse operations, human resources. All of these people need to use software to do their jobs: the accountants need to make journal entries; the warehouse staff need to log shipping manifests; HR needs to run payroll.
We have thousands of people logging into countless different SaaS applications. It's not practical to have people use passwords, both because that'd be inconvenient and because people would exercise poor security hygiene (e.g., keeping passwords written on sticky notes on their desk).
Instead of having all of its employees use passwords, MegaCorp uses a centralized piece of software called an identity provider (IDP) to handle logins. (Common IDPs include Okta, Microsoft Entra, and SailPoint; if you've worked at a big company, you've likely used an IDP!)
Each employee has exactly one password, which they'll use to sign into the IDP. From there, the IDP brokers access to all of the different software applications, which simply trust the IDP. For example, an employee can't just log into Slack software directly; they instead need to enter a password in Okta to access Slack.
As I mentioned above, there are actually a few different technologies that enable this same login flow. It's out of scope to cover all of them here. However, if you hear someone say "SSO" without any further clarification, you can safely assume that they're referring to a specific technology called SAML (Security Assertion Markup Language). I cover how SAML works in another post here.
What is OAuth?
OAuth is a specific technology -- a specific standard -- that software applications use to share information about users with other software applications.
Let's skip to an example here. Have you ever played Words with Friends? It was a really popular Facebook game years ago. Part of the idea (as the name would suggest) was that you'd play against your friends. It's not as much fun to play against RandomScreenname90410. To make that social mechanic work, the game needed to know some information about you: for example, your name, your profile picture, and your list of friends.
There's a bit of a challenge there, though. How can Words with Friends get access to your Facebook data? It can't just go and take it. You need to grant access.
That's essentially the problem that OAuth solves. OAuth is a technology that enables a third-party application like Words with Friends to request authorization to use or modify a user's data from another software application (Facebook, in this case).
OAuth pops up everywhere. Ever seen someone use a Calendar link service like Calendly or Cal.com? Those apps need to use OAuth to look at your calendar. It turns out that having a mostly-standardized way of granting apps access to your data is really useful!
How do OAuth and SSO work together?
Okay, so for the most part, they don't. At least conceptually, you should do your best to keep these separate in your mind. You can have SSO without OAuth, and you can have OAuth without SSO.
However, we can use them together. We can use the OAuth technology to achieve one kind of SSO.
Remember how I mentioned that Words with Friends wants to know what my name is? OAuth is really useful for communicating details about users' identities. We can therefore use OAuth as a way of logging people in! A technology called OpenID Connect (OIDC) outlines how to achieve SSO using OAuth.
Have you ever clicked a button marked Login with Google? Here's an example using chess.com's login page:
This is effectively chess.com asking Apple / Google / Facebook to share data about you over OAuth; concretely, chess.com is asking for some kind of unique identifier. That way, you can repeatably use Apple / Google / Facebook to access the same chess.com account. In essence, chess.com is choosing to trust Apple / Google / Facebook's claims about who you are. That's OIDC -- using OAuth to power SSO.
Summary
Single sign-on (SSO) is an authentication pattern made possible by different technologies. In SSO, successful authentication into one software application (e.g., Okta) confers access to a separate software application (e.g., Slack, Zoom, etc.).
OAuth is a specific technology. It enables a user to grant one software application access to his data in another software application.
SSO and OAuth are not alternatives. In fact, it is possible to use OAuth to drive a specific variety of SSO called OIDC.
However, people do not use terminology precisely in the real world. If someone mentions "SSO" without further clarification, they are almost always referring to a specific technology called SAML.
Tesseral
If you're feeling frustrated as you navigate the particularities of auth and user management, you may find Tesseral helpful. Tesseral is open source auth infrastructure for B2B SaaS. With just a few lines of code, you get everything from a beautiful login page to single sign-on and more.
