OpenID Connect Overview

OpenID Connect Last Updated: 04 April 2015


Much to everyone's disappointment, OAuth 2.0 is not an authentication protocol. Instead it is a protocol designed for requesting access tokens and passing them along to a third-party application, it is an authorization framework.

Over the years a lot of people have tried to turn OAuth into an authentication protocol which is why we have so many different providers, each with their own implementation depending on their view on the universe. Unsurprisingly if you look at the list of top OAuth providers it is eerily similar to the list of organisations who have been hacked in recent years. Creating your own authentication protocol is no simple task...

OpenID Connect 1.0 is a simple identity layer on top of the OAuth protocol. This allows you to provide authentication whilst still using OAuth, but doing so based on a set of specifications, extensions and defined endpoints, allowing us to use authentication securely and with minimal effort for the consumer. It allows combined authentication and authorisation in one round trip.

OpenID Connect defines a standard token type, something that OAuth never did, instead only stating that what an access token is, leaving others to decide on the implementation, again not an easy task. This defined token allows for simple interoperability; one OpenID Connect library which can connect to any arbitrary provider.

It also defines an identity token, a dedicated token type used for authentication that describes the user authenticating with the system.

Other features that have now been standardised are cryptography (defined and widely accepted security for tokens) and token validation (a standard that OAuth never explicitly told the developer how to implement).

Further details such as the various endpoints and flows will be covered in the next post and then I'll start showing some implementation examples using Thinktecture's Identity Server.

Share this article: