Heads up… this article is old!

For an updated version of this article, see What the Heck is OAuth? on the Okta developer blog.

Update 5/12/2016: Building a token authentication with OAuth? JJWT is a Java library providing end-to-end JWT creation and verification, developed by our very own Les Hazlewood. Forever free and open-source (Apache License, Version 2.0), JJWT is simple to use and understand. It was designed with a builder-focused fluent interface hiding most of its complexity. We’d love to have you try it out, and let us know what you think! (And, if you’re a Node developer, check out NJWT!)

Read more about OAuth and token authentication in our Guide to Token Authentication, or our Product Documentation.


We’ve been on a conference blitz over the last few months at Stormpath, and standing in the booth, we get asked a lot of questions about authentication and authorization: protocols, systems, services and security.

Two areas where the misinformation – and therefore misunderstanding – tends to hang out, are Oauth and Single Sign-On. And where they intersect.

To Start, OAuth is not the same thing as Single Sign On (SSO). While they have some similarities — they are very different.

OAuth is an authorization protocol. SSO is a high-level term used to describe a scenario in which a user uses the same credentials to access multiple domains.

What the Heck is OAuth?

OAuth is an authorization protocol that allows a user to selectively decide which services can do what with a user’s data.

For instance, if you attempt to log into Spotify using Facebook, you’ll be redirected to Facebook’s website and will see something like the following:

Spotify Facebook Login with OAuth

What’s happening is that you’ve authenticated with Facebook directly, and now you’re being asked for Spotify’s permission to access YOUR data. This is an authorization request (e.g., what can Spotify do, what can they NOT do?).

OAuth’s primary purpose is to give users more control over their data, so you can selectively grant access to various bits of functionality for various applications that you may want to use.

NOTE: I covered this in depth a few weeks ago in an OAuth specific article I’d highly recommend reading if you aren’t already an OAuth expert: What the Heck is OAuth?

What the Heck is Single Sign-On (SSO)?

Single Sign-On, on the other hand, is a not a protocol — it’s more of a high-level concept used by a wide range of service providers (sometimes with confusing differences).

SSO is an authentication / authorization flow through which a user can log into multiple services using the same credentials.

For instance, at your company, you might want to use one set of credentials to access:

  • Your internal company website.
  • Your Salesforce account.
  • Your Atlassian account.
  • etc.

Instead of making each employee at your company create different accounts for each of those services they use all the time, you can instead create a single account for each employee that grants them access to all of your company services.

This is SSO.

One of the main benefits to using SSO is that your users have only a single account and password to remember which gets them into all of their services. This typically makes account management / user data storage simpler for employees, as there’s less duplicate data floating around between systems.

If you’re working on projects at a large company, SSO can be a really nice way to manage your users. You have a lot more control over user accounts and user data: you retain this information and interface with providers using the Security Assertion Markup Language (SAML).

Essentially what happens is this:

  • You store your user accounts in your own internal system.
  • You create a SAML-compatible interface to talk to various SAML providers (like Salesforce, Microsoft, etc.).
  • Your users can then authenticate just once, and log into any of the compatible providers.

If you’d like a more in-depth introduction to SSO and SAML, I’d highly recommend reading the Salesforce Single Sign On Guide. It does a great job of explaining what all the benefits of traditional are, and how to implement things properly.

OAuth vs. SSO: Which should I use?

At the end of the day, there are really two separate use cases for OAuth and SSO.

If you want your users to be able to use a single account / credential to log into many services directly, use SSO.

If you want your users to have accounts on many different services, and selectively grant access to various services, use OAuth.

And… If you want to support either OAuth or SSO, go create a Stormpath account! We make it really easy to do both!