A conversation we often have with SaaS vendors is whether to choose OpenID or SAML as the single sign-on protocol. With Google having chosen OpenID as the single sign-on protocol for their Apps Marketplace, OpenID may seem like the obvious choice for most people. But SaaS vendors should be aware of the differences between the two before making a decision.

SAML is often criticized for its complexity and OpenID praised for its simplicity. Let's have a look.

Identity providers

One of the advantages of OpenID is auto-discovery of the identity provider. For example, the OpenID https://identityproviderx.com/joe/ tells us that Joe's identity provider can be found at https://identityproviderx.com. This is a great feature for consumers because it simplifies configuring an app for SSO, but as explained further down it becomes a drawback in an enterprise context. There are also many cloud-based OpenID identity providers to choose from.

In the past, SAML has predominantly been used for large enterprises who implemented expensive SAML projects based on standard software licensed from some of the big software vendors. With the emergence of cloud-based identity providers like OneLogin, even the smallest company can now afford to use SAML.

Initiation of the single sign-on process

Single sign-on can be initiated in two ways:

• Service provider initiated – the application initiates SSO when the user tries to sign in
• Identity provider initiated – the identity provider initiates SSO when the user launches the app from a portal

OpenID supports only service provider initiated SSO and the user is often required to enter the OpenID manually. SAML supports both forms, which means that it is possible to provide end-users with portals where they can launch all their apps. Some applications will accept an OpenID via an http POST request, but this is far from always the case.

User provisioning

Provisioning in this context means enabling a user to sign into an application. This is usually done by a user with admin privileges, for example a Salesforce administrator. As the number users in an organization increases, managing users in the various cloud applications can become an administrative hassle and this is where OpenID and SAML differ as well.

For OpenID to work, every single user in an application needs to have its OpenID registered in that application. SAML is able to sign users in based on their email address or username, which makes it much easier to adminster. Consider an example where an application has 100 users. To enable SSO via OpenID, it would be necessary to configure the OpenID on each of those users in the application. To enable SSO via SAML, all that's required is to configure a couple of URLs and upload an X.509 certificate or fingerprint.

Both protocols can support just-in-time provisioning, which means that the application creates new users as they are signed in via SSO. SAML can do this in the same request whereas OpenID must make a back-channel SReg request.

Performance

OpenID and SAML have different performance characteristics. SSO in OpenID always starts with a back-channel request to the identity provider, which was extracted from the OpenID URL. After this request, the user's browser is redirected to the identity provider to allow the identity provider to sign the user in. 

SAML, in comparison, is based exclusively on browser redirects. If SSO is service provider initiated, the user's browser is redirected to the identity provider, which will insert a SAML response and redirect the user back to the application. If SSO is identity provider initiated, i.e. the user launched the app from an SSO portal, the identity provider simply redirects the browser to the app with a SAML response included in the request.

The end-user experience is typically that SSO via SAML is smoother and faster.

Implementation

One of the reasons many vendors choose to implement OpenID is because it is simpler and there are toolkits for it in every web development framework available. The SAML standard is complex and it is harder to obtain a SAML toolkit that's easy to implement for your particular framework. This is why OneLogin has open-sourced SAML toolkits for Ruby on Rails and PHP.

Adoption

OpenID is often reported to have hundreds of millions of users enabled. But people are not aware that they have an OpenID and many find OpenID difficult to understand. OpenID is mostly positioned as a consumer feature and has seen very little adoption in the enterprise, perhaps because of the lack of enterprise class OpenID providers.

Comparison table

The table below summarizes the differences between the two protocols.

Conclusion

SAML has some clear advantages over OpenID when it comes to enterprise single sign-on and we are seeing increased interest from SaaS vendors in adding SAML to their applications. If you are considering going the SAML route, feel free to contact us at vendor@onelogin.com with any questions.