Single Sign-On with SAML or JSON Web Tokens
What can one less login do? Quite a lot. Retain a few customers. Retained customers add most value so revenue goes up substantially. So what do you reckon would a lot less instances of logins do to a business? Anyone’s guess.
That’s exactly why Single Sign-On is becoming a rage of sorts with both enterprises and Small and Medium Businesses alike because their employees and customers don’t have to re-login multiple times to access multiple applications. Of course, this is also because businesses are now forced and accustomed to running multiple websites and applications. So, in such a situation, Single Sign-On basically allows customers of a business to access all the websites and applications on offer after logging in just once. Effectively, subsequent access requests after the first login are authenticated on the basis of certain tokens created during the first login. But there are several ways of doing this which gives way to the natural question about which is the best one. This post will try to answer that and it is almost certain it will fail to answer the question: “Which is the best Single Sign-On implementation method?” But, it will try to help you identify which could be the more apt Single Sign-On implementation method for you because there’s no one-size-fits-all here and businesses just have to pick and choose according to their environment and requirements.
What is Single Sign-On, in a nutshell?
Single Sign-On is an authentication process by way of which a person can access multiple web properties or applications after logging into any of them just once. So. if there are website A, website B and website C owned by a single business group, and a customer logs into website B entering his or her correct credentials, the customer is given access. Now, in the same session, if the customer wants to access website A, he or she can directly do so and will not have to login again because she did so on the first point of contact. How Single Sign-On helps is by removing multiple login hurdles, not forcing a user to create multiple accounts and remember multiple passwords and so on. You can just think of a nice advantage in your current implementation, it’s that useful. It has been around for some time now which is exactly why there are multiple methods of Single Sign-On implementation but it is only gaining wide-scale acceptance now.
Does the implementation vary by environment or context?
Of course it does, in the sense that an enterprise implementation of Single Sign-On will be different from web implementation. The latter is more frequently called Web Single Sign-On. And then Web Single Sign-On differs slightly in implementation from mobile Single Sign-On. Web and mobile Single Sign-On implementations are cousins of sorts but there enterprise Single Sign-On sometimes is wildly different in the sense that it operates by installing the SSO agent at each terminal in use in the enterprise. This works because the enterprise network is only for the employee and they are expected to come to office and work. Obviously, that is no longer the case and even enterprise Single Sign-On implementation methods started inching towards Web Single Sign-On as enterprises started allowing employees to work remotely. In such scenarios, employees needed to access the enterprise network resources from remote locations over the Web.
What the are the common means of SSO implementation?
Now we are really getting the interesting part. Single Sign-On, as we know it, can be implemented using multiple technologies. The foremost among them using SAML to create the authentication token and pass it. A similar technique is used to implement SSO but with JSON Web Tokens, also called JWT (pronunciation the same as ‘jot’). And then there are methods using the traditional cookies and something called Multipass that a few businesses use. The tussle here is between SAML and JSON Web Tokens. Both can be used to implement Single Sign-On and effectively at that. JSON Web Tokens, as is quite obvious, is based on the JSON data format and accepted widely throughout the Web. SAML, on the other hand, is based on XML.
What about OAuth?
OAuth is not an authentication protocol but an authorization framework. Among other authentication paradigms, Social Login is implemented using OAuth. But isn’t Social Login just authentication, so why not use SAML or JWT instead. Well, the simple reason is that SAML and JWT can help authenticate customers but aren’t too good at authorization. Unlike its name, Social Login isn’t just about signing in using a social identity but also about extending social functionalities to the business website being logged into which is where OAuth comes in.
So, it is SAML SSO vs JWT SSO?
Sure it is. But the key question is which one to pick. Interestingly, this question doesn’t have a single answer. In fact, both the answers SAML based Single Sign-On and JSON Web Token based Single Sign-On are correct. And both can be wrong. How’s that? It’s simple. Which technology you choose depend on what you are already working with and in which context. SAML is based XML, as we already mentioned and XML is a sort of an enterprise markup language with a lot of baggage. True, it gives a lot of information but it can become heavy when you don’t need all that information. XML is like carrying a huge suitcase on a two day business trip. But then again, XML is a standard accepted data representation protocol in enterprises. It is also true that XML was initially also meant for the internet. But then came along the JavaScript age which brought its own support staff of JSON which is also an object notation format. JSON is totally compatible with JavaScript and with the latter ruling the Web in recent times, JSON obviously found its golden days. Of course, it’s advantageous that JSON is really compact and easy to transfer. XML is much bigger in terms of stature as well. So, if you are implementing Single Sign-On for an enterprise grade application, it makes sense to go for SAML based SSO. But, if your offering is just a lightweight web service, JWT should be the pick for you.
