DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations

Trending

  • Apache Kafka vs. Message Queue: Trade-Offs, Integration, Migration
  • File Upload Security and Malware Protection
  • Logging Best Practices Revisited [Video]
  • Redefining DevOps: The Transformative Power of Containerization
  1. DZone
  2. Software Design and Architecture
  3. Security
  4. A Brief History of Security Protocols

A Brief History of Security Protocols

Security protocols follow their history.

Jérôme Leleu user avatar by
Jérôme Leleu
·
Nov. 04, 19 · Presentation
Like (0)
Save
Tweet
Share
719 Views

Join the DZone community and get the full member experience.

Join For Free

laptop-half-way-closed

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.
security Authentication protocol History (command)

Published at DZone with permission of Jérôme Leleu. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • Apache Kafka vs. Message Queue: Trade-Offs, Integration, Migration
  • File Upload Security and Malware Protection
  • Logging Best Practices Revisited [Video]
  • Redefining DevOps: The Transformative Power of Containerization

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: