Despite big-name support, newly finalized OpenID Connect protocol is a security building block, not a silver bullet.
After some four years of wrangling, the OpenID Foundation has finally given the thumbs-up to OpenID Connect, its protocol for both authenticating users and providing a distributed way to handle privacy and permissions.
But a protocol by itself is a long way from being a full solution to the nasty hash of credentials, mechanisms, and standards that developers and administrators have to deal with whenever the word “security” enters the conversation.
OpenID Connect isn’t OpenID 2.0, which gained little traction as the single-sign-on solution it was intended to be. It’s an identity layer that uses OAuth 2.0, and it’s billed as being able to do the same things OpenID 2.0 did, as well as stuff OpenID 2.0 could never do, such as provide access tokens. Data is passed around using REST calls and JSON, obviating the need to create firewall exceptions and making it theoretically easier for developers to implement than OpenID 2.0.
The OpenID Foundation describes OpenID Connect this way: “[It] lets developers authenticate their users across websites and apps without having to own and manage password files. For the app builder, it provides a secure, verifiable answer to the question: ‘What is the identity of the person currently using the browser or native app that is connected to me?'”
You don’t need to look very far to find a working example of OpenID Connect: Google.
Google has been bullish enough on the technology that it took its existing Google+ Sign In technology, originally built with OAuth 2.0, swapped in OpenID Connect, and deprecated use of legacy OpenID. Microsoft and Salesforce — two big outfits who’ve locked horns before over who gets to be the bigger and better identity provider — are also backing OpenID Connect. And work is set to begin on figuring out how to use mobile phone accounts as an OpenID Connect identity in Europe.
Consequently, OpenID Connect is a building block, not a silver bullet by itself. That said, it’s possible one or more powerful federated identity solutions could arise from it, each connected in a central way that would make juggling passwords obsolete. Such an arrangement might also constitute one way to deal with the problem of living in an age where multiple digital identities are a good idea and not a bad one.
But the resulting implementations will need to hold up under scrutiny better than OpenID’s previous implementations did. Back in 2013, Facebook’s OpenID implementation was found to be sporting a bug severe enough to pay out a $33,500 bounty to its finder. And back in 2012, a study of OpenID implementations found many of them to be poorly implemented, and the OpenID implementation of Mozilla’s own Persona identity management service was shown to have vulnerabilitiesas well.
If switching to OpenID Connect makes it easier for the developer to avoid those kinds of errors of implementation, it’ll automatically be a step in the right direction. For now, it’ll help to start with the existing real-world deployments like Google+ Sign In and see how they fare.