Could OpenID Connect solve federated sign-in problems?

Last week I took to our tech blog to outline how we went about implementation for our just-launched Social Sign-in feature. In it, I spoke about a number of implementation issues that came about with the use of OAuth 2. For example:

“…once you have the OAuth 2 access token, all of the [federated auth] services offer completely different APIs for getting hold of data about the user. For this, in the end, we resorted to writing custom implementations for each provider.”

Just yesterday, the OpenID Connect Work Group announced that the final OpenID Connect specifications were completed and launched. OpenID Connect is backed by a number of large organisations, including Google who announced they will support it for Google+ Sign-in, and includes a number of interesting features for developers looking to work with federated sign-in.

Can OpenID Connect make up what OAuth 2 doesn’t cover?

The OpenID Connect description says:

“[OpenID Connect] is API-friendly, and usable by native and mobile applications”

This sounds like a huge leap forwards from OpenID 2.0 and other associated standards that made it simply too complex for developers to integrate. Additionally, it is underpinned by OAuth 2 standards as shown in this architecture diagram (along with a LOT of acronyms):

OpenID Connect protocol suite OpenID Connect protocol suite

But by far and away the best part of OpenID Connect is this:

“[OpenID Connect] enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.”

One of the core issues I raised in the Social Sign-in blog post was that once you have an OAuth 2 token, there is no standardisation at all when it comes to obtaining data about the user that just logged in – and it looks like OpenID Connect aims to address this issue, as well as others.

(If you’re interested in the details about getting the user data, this is the relevant section of the spec).

Success depends on support

OpenID Connect looks very promising from an implementer’s point of view – finally we no longer need to create different implementations to get user data from the various services we support. However, as with all of these things, success of the protocol on a whole depends on its support. Google have gone a long way and have implemented this standard already, but until multiple providers are ready to ship complete support, then Connect will suffer.

Additionally, OpenID Connect implementers will need to ensure that their systems match the specification completely. One of OAuth 2’s major issues was an (in parts) ambiguous spec which lead to differing implementations between services. This has been partially addressed by the high-quality specification of OpenID Connect, and hopefully this will drive implementers in the right direction and provide great compatibility between services.

Extract data from almost any website