I receive a lot of emails regarding my post Choosing an SSO Strategy: SAML vs OAuth2. The two common questions seems to be: 1) Did you make the right decision going with OAuth2 and 2) Should I go with SAML or OAuth2?
The answer to the first question is simple: Yes, OAuth2 was the right choice for that application. Integration itself was simple and it supports all of the use-cases that our customer had (including their goal of supporting native applications). It's still in use today and we haven't had to mess with the integration since its initial deploy.
There are two ways to consider the second question. My default response is to go with OAuth2. If you want to know why then you'll need to keep reading.
Before you can choose the appropriate solution you need to figure out what part of the equation your application is looking to fulfill. There are two roles that your application (or platform) will fit into regardless of using OAuth2 or SAML: the Resource Server (aka Service Provider) and the Authorization Server (aka Identity Provider).
Being A Resource Server; Not An Authorization Server
If you don't want your application to store user credentials, but you want users to be able to log in to your application with credentials they may have on another site (e.g. Google, Facebook ,Twitter, etc) then your application will be a Resource Server.
This means that Google, Facebook, Twitter, etc will be the Authorization Server. The nice thing about being a Resource Server is that it's a lot less work to implement and maintain, since many of the decisions have been made for you. The potential downside is that you'll have to implement the authorization flow that they support.
If you want to support the ability for users to log in from more than one auth provider (e.g. a user could log in from either Twitter or Google or Facebook) then your application will need to implement one or more authorization flows based on what they support. This may mean you end up implementing OAuth2, SAML, OAuth 1.0, or possibly something different or custom altogether.
Fortunately, in practice this isn't so bad. There are usually auth-provider specific libraries available for a variety of programming languages which hide the complexity of the authorization flows and provide a simpler interface for your application to use in order to authentication/authorize.
Here's a list of common authorization servers commonly referred to as "social identity providers":
- Google: OAuth 2.0
- Facebook: variant of OAuth 2.0
- Twitter: OAuth 1.0a for users and OAuth 2.0a for applications
- Yahoo: OAuth 2.0 for products like Yahoo Gemini and Yahoo Social APIs but for the rest its OAuth 1.0a
- LinkedIn: OAuth 2.0
- Github: OAuth 2.0
Third-Party SSO and Local Credentials
A common question when someone finds out their application is a resource server is: If people don't want to log in via third-party, can I still let them create accounts on my site and log in with those credentials or does my application need to become an SSO-capable authorization server?
Somehow, people feel that when their application allows for third-party authentication their app needs to become a full-blown SSO authorization server out of the gate. This is a myth. It's not true.
Your application can take advantage of third-party SSO and still allow users to create local accounts which don't have SSO. You only need your application to be an SSO-capable authorization server if you want other sites, apps, etc to use your application for authentication/authorization.
Being An Authorization Server; Not A Resource Server
If the goal of your application is to manage user credentials and to allow other sites, apps, etc to authenticate with those credentials then your application is filling the role of being an Authorization Server.
Now deciding between OAuth2 and SAML becomes relevant because your application will indicate how other apps integrate with it for authentication/authorization.
Let's walk through a few scenarios to see what you should go with.
Native Mobile Application Support
Do you want native mobile applications (without a web-server backing it) to be able to authenticate against your authorization server? If yes, then go with OAuth2. In fact, you can't even consider SAML because it doesn't support a native application authorization flow due to its design.
The only way for SAML to work with a native application is for the application provider to have a web-server somewhere that can handle the authorization flow. This workaround will work and is how Okta allows for SAML to work with native applications.
The downside of this workaround is that you put more burden on the third-party app provider. They can no longer just ship their app and use your service to authenticate; now they have to also build a web-application that handles the authorization.
This may not sound like a big deal but it's yet another code-base and application to build, deploy, and maintain. Oh and don't forget to purchase domain names/SSL certificates/hosting and keep those up to date as well.
If you want native apps to use your authorization server just go with OAuth2. It's far simpler for you to build and maintain with the added benefit that it's far simpler for other app developers to integrate with as well.
When You Don't Care About Native Mobile Applications
When you only care about web applications (or native applications that have an accompanying web-server implementing an auth workaround) then you really have a choice between OAuth2 and SAML. This begs the question: Who doesn't want to allow for native applications to authenticate?
These days it's pretty impractical to cut out native mobile application support from your auth flow. This makes new SAML-based auth flows seem pretty futile although I know it's still prevalent in the enterprise world.
When you're building an authorization server from the ground up my recommendation is to start out with OAuth2. Even though SAML is technically a choice it's an anachronism in today's mobile dominated world. OAuth2 is far simpler and will take you farther for less.
You can get a comprehensive understanding for how OAuth2 works in RFC 6749 by reading 75 pages whereas the SAML 2.0 specifications (core, bindings, profiles, metadata, conformance) amount to 265 pages.
In my opinion, RFC 6749 is also much easier to read and digest compared to the SAML 2.0 specifications.
Buying and Configuring An Off-The-Shelf Authorization Server
If you're working for an organization that doesn't want to implement the authorization server, but wants to buy an off-the-shelf product to configure, then you have some options:
- Okta - IDentity provider as a Service platform (IDaaS). Cost varies depending on whether you're only allowing internal users to your organization to log in or if you want external users to log in as well.
- OneLogin - IDaaS
- Ping Federate - IDaaS and site installation(s), closed source.
- WSO2 Identity Server - Open-source and technically free, but to use it you will 100% need to buy a support contract.
- Shibboleth - Free and open-source.
- Gluu - open source platform built using other open source components like Shibboleth, you buy support contracts.
For even more alternatives, here's a list of Ping Federate competitors.
The nice thing about going off-the-shelf is that most of these products support a number of authorization flows (e.g. OAuth2, OAuth 1.0a, SAML, etc) out of the box. If your team is not a development team, but more of a system admin/integration team then off-the-shelf will look even more appealing.
The downside of going off the shelf is that you will get a lot of stuff you don't need and you'll have to suffer through often clunky user interfaces and configuration files to do what you need. All of the off-the-shelf products that aren't IDaaS will likely require support contracts to get up and running. There can be a big learning curve for your team to understand not only the products, but the authorization flows and how to configure and use them.
With all of that said it may still be cheaper to pay for a support contract to get you up and going than to hire a development team and build your own platform from the ground up. In some cases you may need a little bit of both if you need any kind of custom integration or customization to the authorization server product.
IDaaS products like Okta, OneLogin, etc are very interesting to me because they continue to shift the burden to the provider. It seems like you'd have far fewer headaches over time because you don't have to worry about patching and upgrading local installations. Instead, you'll get most of those automatically as soon as they're available. The downside here is that customizations and local site installations may not be an option.
When OAuth2 Is Too Open-Ended
A common complaint around OAuth2 is that it's not specific enough and leaves too much open for variation. For example, OAuth2 doesn't specify how you should be able to obtain user profile information (if at all), but most OAuth2 providers provide a way to do that, it just may be different across providers.
Enter OpenID Connect; a layer on top of OAuth2. From its site, OpenID Connect:
allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner
Earlier this year a certification program for OpenID Connect was launched. The first to self-certify were Google, Microsoft, Ping Identity, ForgeRock, Nomura Research Institute, and PayPal. Additionally, Salesforce also supports OpenID Connect.
If you're worried about interoperability you now have a variety of providers and products which all adhere to the same standard for retrieving user profile information using OAuth2 flows and the list is growing.
Even though OpenID Connect is relatively new it has been in the works for the past two years and has developed a large number of libraries for various programming languages.
When SAML Is An Actual Option
SAML is a real option when you have a legacy or enterprise infrastructure that already uses SAML. When you want to tap into that infrastructure then SAML is a strong contender. However, with the rise of OAuth2 and OpenID Connect, SAML will soon be relegated to legacy infrastructure and integrations.
For example, Microsoft's cloud platform Azure Active Directory supports SAML SSO, but as of September 2014 it released OAuth2 and OpenID Connect for general availability.
In Closing
Now that we both have a good understanding of the trade-offs between OAuth2 and SAML we can re-ask the question: Should I work with SAML or OAuth2?
The rule of thumb is to look at OAuth2 based solutions first. If you can't disqualify OAuth2 for your needs then you'll have a solution that works for more apps out of the box and is far easier to build, understand, integrate with, and support.
For the times when SAML integration is a must you now know some of its limitations and you'll see upfront where you may need to expend extra effort or where to look for third-party providers.
If you're building an application or platform that acts as a resource server or an authorization server and would like any help, a fresh set of eyes, or to offload the work and have it done right – don't hesitate to reach out to us at hello@mutuallyhuman.com.