This is the second blog post (part 1 available here) where we look at the history of open source identity management. This post focuses on Oauth and OpenID, the protocols currently used in modern applications and services.
This post does not cover the technical details of the open source identity management standards, which are explained very well in this Okta blog post. Rather, it explains the origins of Oauth and OpenID, and provides insights on the context that led to their creation.
Towards modern open source identity management
As we wrote in the previous article, in the late 1990s and early 2000s, identity management was widely believed to be a solved problem. However, two computing trends quickly challenged that common belief:
- REST – In 2000, Roy Fielding led the basis for REST APIs in his dissertation, Architectural Styles and the Design of Network-based Software Architectures. It provided one of the key architectural patterns still used to this date.
- Mobile phones – The popularity of Blackberry, Windows Mobile, Palm, Symbian and later iOS and Android was increasing year by year, forever changing the way people consume information.
In both cases, the existing identity and access management frameworks were unfit, and required relatively complex implementations with high operational costs. This led to a number of new standards being developed by small and large companies alike, and eventually the two described below.
The OpenID protocol was initially developed in 2005 by Brian Fizpatrick under the name of Yadis (the original post is still available here) while working on the Livejournal website. The protocol was born as a way to give users the possibility to be authenticated by cooperating sites (called relying parties) using a single internal or external identity provider, effectively eliminating the need to have separate credentials across different sites.
From the early days, OpenID grew rapidly, thanks to the contributions of many corporations and the community. The most notable early contributions were made by JanRain, which developed the original OpenID libraries in many programming languages, and NetMesh, which added the Extensible Resource Descriptor Sequence (XRDS) format initially used in their Light-weight Identity (LID) protocol.
At the time, OpenID was competing with Microsoft’s CardSpace and the Eclipse Foundation’s Higgins Trust Framework. However, OpenID gained significant traction, thanks to the endorsement received by the major tech giants, including Microsoft, which saw in it a way to help their users easily reuse their identities across the internet.
The meteoric adoption of OpenID and the growth of its community prompted the creation of a formal governance body to promote its adoption and manage its evolution. In May 2007, the OpenID foundation was formed with the mission of promoting and enhancing OpenID technologies and standards. The organisation is still active, and its members include some of the most notable names in tech, telecommunication, and professional services.
OAuth was started in 2006, and its conception is closely tied to OpenID. When Blaine Cook (one of the co-authors of the original OAuth spec) was implementing OpenID for Twitter API, he realised that there wasn’t a single effective way of providing secure delegated access to it.
In that period, both the number and popularity of social media websites was growing exponentially, and with them, the need to “connect users with their friends”. In order to enable that, social media sites were usually asking users to share their login credentials to other services they were already using (e.g., their email provider) to see which contacts were already on the platform and send invitations to the ones that were not. This meant users had to make a tradeoff between their security and the thrill of finding new friends.
OAuth was not supposed to be a new protocol, but rather a standardisation centered around bringing the best aspects provided by the other protocols in use at the time (such as Yahoo BBAuth, Google AuthSub, AWS API, etc.) under the same umbrella. Each one of those provided a semi-customised way of exchanging user credentials for an access token that was primarily targeted at website services.
The other major innovation introduced by OAuth was its ability to operate well on traditional websites as well as native mobile applications and connected devices. Version 1 of the spec was released in 2010, and version 2 (currently in use) in 2012 with RFC6749 and RFC6750.
While OAuth and OpenID flows share the same actor names and some architectural components, they are complementary standards that serve different purposes. OpenID was intended as a way to use a single identity to access many sites, while OAuth allowed users to provide access to some of their private resources to different sites without sharing their authentication credentials.
OpenID Connect (OIDC)
Given the success and rapid adoption of OAuth, many developers decided to “hack it” to use it as a way to perform authentication and pass identity information. However, this presented several security challenges. These challenges, coupled with evolving architectural needs, prompted the creation of the third version of OpenID, called OpenID Connect (or OIDC).
OIDC is an identity layer built on top of the OAuth flow. It was officially released in 2014, and since then it has become the de facto authentication standard in both the consumer and enterprise space with several billions of OIDC enabled identities in both the consumer and enterprise markets.
Despite OpenID Connect and OpenID sharing the same name, they are two very different standards with different parameters and response body formats. OIDC combines the features of OpenID 2.0, OpenID Attribute Exchange 1.0, and OAuth 2.0, allowing an application to use an external authoritative service to:
- Verify the user identity
- Get the user profile information in a standardised format
- Request approval and gain access to the required subset of users attributes
Nowadays, OIDC is not only the internet identity layer, but also the standard with which we provide secure access to our financial information online via the Financial Grade API (FAPI), with a very active working group shaping the future of finance.
The future looks bright for identity management, and at Canonical we work hard to support the standard and its flows in our suite of products.