Single sign-on has a complicated history. If you look at it from a protocol point of view -- OpenID, Security Assertion...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Markup Language (SAML), Oauth, YAML and Shibboleth, among others -- the technology seems complex and maddening. The history is simpler if you look at it by instead using Active Directory as the logical single sign-on (SSO) hub. But the market for SSO services has grown beyond these origins and evolved as identity providers have moved toward cloud-based identity systems and as more software as a service (SaaS) application vendors support a variety of SSO tools. Let's look at where SSO has been and where it stands today in order to help enterprises determine the best ways to deploy an SSO service in the future.
What is an SSO service, and how does it work?
SSO works its magic by using a variety of mechanisms to automate the sign-on process. It is still used for automating logins to local network resources, such as databases, via secure scripts or using one of the identity protocols. This automation is just one part of the story: You also want to be able to quickly provision all of your users on these various servers and services. And there are now SSO tools that can operate either in the cloud or on-premises, and some that put pieces of their technology in both places. That's the good news. The bad news is that there are almost too many choices in how to implement them. In particular, the field of protocols is split between OpenID and SAML as the most popular ways to connect to various applications.
OPENID vs. SAML: Which does what?
The two protocols an SSO service may use differ in terms of how they can be used for just-in-time user provisioning, how they interact with service and identity providers in the SSO connection dialogs, their relative performance, how they are positioned in terms of consumer or enterprise software plays and the number of known security vulnerabilities.
Not surprisingly, organizations need some guidance when choosing the appropriate protocol to implement an SSO service. With that in mind, let's look closer at each. SAML was created in 2002 as a way to exchange XML information among various websites. It has since grown into its role of providing common logins among trusted sites. OpenID came out in 2006 and was designed to enable consumers to use a single login among numerous websites. But the sites don't have to necessarily have this "circle of trust," or a way to establish secure communications among your SaaS app and your user directory and SSO application. A number of popular Internet application providers now support it, including Google, Twitter and Yahoo. An SSO request can be initiated in one of two ways, either by the service provider (such as the application site itself) or by the identity provider (the SSO vendor). SAML supports both methods, but OpenID only supports the former. This means that if you choose to implement SAML, you can create a Web-based portal page that has icons and links to the various apps that you want to sign on to. Most of the popular SSO tools have this feature, which appeals to many enterprise users. With OpenID, you have to bring up the target app on your own. When it comes to performance, SAML is usually cited as a better option, because it makes use of browser redirects and is considered a smoother process. However, OpenID is generally thought of as easier to implement, and has tools in most of the popular Web programming languages to make it easier to incorporate into your own apps. Some of the SSO vendors have their own SAML toolkits, such as OneLogin for Ruby and PHP or Okta for Java, to make integration easier with that method.
How to choose
Neither protocol is perfect. SAML has been the subject of a number of vulnerabilities, while OpenID has seen phishing attacks and can be compromised if the originating email addresses aren't validated. You should proceed with caution on both approaches, and understand these exploits before deploying either of them. Finally, there is the matter of user provisioning. With OpenID, every user of a particular app has to have his or her OpenID credentials registered for that app. That can get tedious if you have to turn on OpenID for hundreds or even thousands of users. With SAML it is much easier, since it works with X.509 certificates and you can enable an entire user population at once. So if you have just a few users or SaaS-based apps, OpenID will be fine; for larger implementations, stick with SAML. SAML will be best for assembling a user portal to all your apps and a better performer over the long run. And if you can employ one of the SAML toolkits, all the better.
Can cloud SSO be secure?
Learn about OpenID Connect
Check out our other single sign-on resources