You are viewing our old blog site. For latest posts, please visit us at the new space. Follow our publication there to stay updated with tech articles, tutorials, events & more.

Choosing an SSO Protocol: SAML over OAuth2

Wednesday, April 29, 2015 | By
0.00 avg. rating (0% score) - 0 votes
Creating a new login for each system is not such a good user experience. As we know it is hard to remember more login credentials as we use more applications, this came as a problem which made us to thing about Single Sign On Service. If you have logged into an application (mobile app or web app) by clicking on a ‘Login/Signup with Facebook’ button you would know what we are talking about.
 
As a user you really doesn’t want to know how SSO works, you just really want to need is a smoother user experience and a fewer logins and passwords to remember. So to provide this functionality we implemented SSO in our application of which we figured out can be done in two ways SAML and OAuth. In this article we have discussed both of the approaches with their significance. But better we start with a little about SSO.
 
 

What is SSO ?

 
Single Sign On (SSO) (also known as Enterprise Single Sign On or “ESSO”) is the ability for a user to enter the same id and password to logon to multiple applications within an enterprise. As passwords are the least secure authentication mechanism, single sign on has now become known as reduced sign on (RSO) since more than one type of authentication mechanism is used according to enterprise risk models.

Why do we need it?

 
SSO is highly essential when you are providing services that are linked to a large number of people in the same organization. As it is more hectic to remember credentials for each and every application separately and almost all the organizations have an account of their users it is better to use SSO instead of creating new accounts for your application.
 
Single sign on would allow the enterprise system to securely store and own all of the user credentials. The platform can establish a trust relationship with the enterprise authentication server and client applications can be built to utilize the trusted authentication server to authenticate users.
 


How SAML works ?

We originally looked into SAML 2.0 which is a set of open standards, one of which is specifically designed for SSO.
SAML and OAuth uses very much similar authentication mechanisms. There are a few terms used in both of protocols.
 
1. Service Provider – The web server trying to access the account details and provides services in exchange of user credentials data (without password).
 
2. Identity Provider – Server which owns user credentials and identities. It authenticates the user and provides the data to service provider once the user is authenticated successfully.
 
3. Client – A web application hosted on a server which needs the user interaction on mobile application / web browser.

This is how it works!
 


 
 
1. User opens the browser and goes to the service provider URL.
 
2. Service Provider findsno user data and redirects user to Identity Provider with a SAML Authentication Request. To send the request, Service Provider signs the request, encrypts it and encodes it and sends it.
 
3. Identity Provider receives the request and validates it. If found valid, it verifies the signatures. On signature verification, user is redirected to the Identity Provider’s login page having a form with username and password.
 
4. Once user is logged in, Identity Provider generates a SAML Token that includes user identities (name, email,etc.). Then Identity Provider redirects back to the Service Provider with SAML Token.
 
5. Then the browser calls for the assertion consumer service of Service Provider to ensure that the data is coming from correct source or not. Assertion involves verification of the signature.
 
6. Then after the assertion the actual data is decrypted and send back to the page where the user data is required.
 
7. After receiving the correct user identities, a custom login state is maintained at the service provider end for their session. And user is marked as logged in on the service.
 
SAML uses two types of bindings for the redirection of Identity Provider to back to Service Provider which are HTTP POST and HTTP Redirect. HTTP Redirects is goodat sending the messages and are used when there is small user data thatneeds to be transferred. Whereas HTTP POST requires a form to be submitted on the client end for sending the data which causes a problem when implementing over mobile applications.
 
 

SAML vs OAuth

 
OAuth is basically used for Authorization rather than Authentication. It provides a simpler and more standardized solution which covers all of our current needs and avoids the use of workarounds.
 
This is the most common OAuth2 flow: the authorization code flow. OAuth2 provides three other flows (or what they call authorization grants) which work for slightly different scenarios, such as single page javascript apps, native mobile apps, native desktop apps, traditional web apps, and server-side applications where a user isn’t directly involved but they’ve granted you permission to do something on their behalf.
 
This is how it works!
 


 
 
OAuth works over token exchange mechanism which generates an authorization token once the user gets logged in into the Identity Provider and then the authorization token can be exchanged with the Identity Provider to provide the data required as per the requirement.
OAuth2 doesn’t require signing messages by default. If you want to add that in, feel free, but out of the box, the spec works without it. It does prescribe that all requests should be made over SSL/TLS.
 
SAML has one feature that OAuth2 lacks: the SAML token contains the user identity information (because of signing). With OAuth2, you don’t get that out of the box, and instead, the Resource Server needs to make an additional round trip to validate the token with the Authorization Server.
 
Both approaches have nice features and both will work for SSO. We have explained how both of them work. At the end of the day SAML seems to be a better fit for our needs (since there isn’t an existing OAuth/SAML infrastructure in place to utilize). We have implemented SAML in PHP language using open sourced SIMPLESAMLPHP library.
 
SAML provides a simpler and more standardized solution which covers all of our current needs and avoids the use of workarounds for interoperability with native applications.
Posted in General