This is certainly the number one presentation I make when doing consulting missions for my clients. While most people I meet have some knowledge about security protocols, they generally lack an understanding of their historical background, which could help them see a broader vision of security and have the hindsight that would help them make the best choices. So, let’s talk about the security protocols and let’s try to make it a little funny, right?

You may also like: How SAML Authentication Works.

1. SAML

At first, there was SAML. This is a standard of the OASIS consortium, which has produced several standards around XML.

There was a version 1.0 in 2002 and then a version 2.0 in 2005. I don’t hear that much about version 1.0, but version 2.0 is incredibly widespread, not to say popular. In most companies, there is always a SAML IdP (a SAML server) somewhere to be integrated with.

SAML is mainly a web authentication protocol based on XML requests/responses, which makes it fairly verbose. It is rather complicated, and I’m often contacted by people to help them with their SAML integration.

Behind OASIS, you have IBM, Microsoft, Oracle, … and the SAML standard is at their images: heavy!

2. CAS

At the same time or maybe even earlier, there was CAS. It was born at Yale University and therefore widely used in the higher education system.

It’s a standard somehow, but it lacks a consortium or authority behind it. This is why properly returning user attributes has taken too much time to be standardized for example. It’s a protocol but it’s also a software at the same time (the CAS server in Java).

CAS is a web authentication protocol but it targets UIs as well as web services, which was very innovative in the early 2000s. The web services support is unfortunately underused. I still believe in it yet.
Although it’s also based on XML, it’s at the other end of the Spectrum compared to SAML. It’s very easy with limited configuration options (the CAS server login URL is mostly what you need). It’s a protocol made by people who just want to make it work, no licenses or software to sell.

3. OpenID

OpenID came after that in 2007. OpenID is not OpenID Connect (like Java is not Javascript). It’s under the umbrella of the OpenID foundation. It followed the rise of the web, and its members are Yahoo, Google, Facebook.

It’s a web authentication protocol made by web pure players, not software vendors. It was built with one idea in mind: make OpenID identity providers discovery easy based on the OpenID identifier. Putting this idea in practice was fairly complicated, and it has never reached the expected success.

It’s a protocol I have forgotten a long time ago and for which I don’t receive any business request for by clients or in the open source space. In one word: dead.

4. OAuth

At the same time, OAuth was born with version 1.0 (2007), and, a few years later, version 2.0 (2012) came to increase its adoption. The story goes that a guy from Twitter didn’t want to use the OpenID protocol from Yahoo and invented his own security protocol.

Version 1.0 was rather complicated with a token exchange, and I almost don’t hear about it anymore. Version 2.0 is much easier, but the original spec was incomplete enough to leave space for custom developments and vulnerabilities. It’s much better now.

As opposed to the previous protocols, OAuth is an authorization protocol. Of course, before getting any authorization, the user must be authenticated, which leads to some confusion on the matter. In the end though, the application does not know the user but gets a token to access the user’s data. Generally, the application can know the user by getting his profile, but this could not be the case.

This authorization nature of the OAuth protocol is not surprising given the rise of web services these last few years and the companies behind the OAuth RFCs: Google, Twitter, Facebook… As we know their business models are mostly to expose our data ;-).

5. OpenID Connect

OpenID Connect was born in 2014; it’s a very new protocol built on top of (the success of) the OAuth protocol v2. Taken from OpenID's official website: “OpenID Connect performs many of the same tasks as OpenID 2.0, but does so in a way that is API-friendly, and usable by native and mobile applications.”

To make things clearer, OpenID Connect is an authentication layer on top of OAuth. Thus it does both authentication and authorization. Related to authentication, some specs deal with the logout mechanism, and the protocol uses the JWT technology to return an ID token containing the user identity (in addition to the access token).

Conclusion

As we know, the world has changed: early websites have been replaced by a galaxy of web services, and the powerful leaders of yesterday have been overwhelmed by the new web players. The security protocols follow history.

Further Reading

• REST API Security.
• Introduction to Security and TLS.
• Authentication and Authorization: Mastering Security.