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:
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 (eg: 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.
Should I Use OAuth or SSO?
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!