Two tastes better together: Combining OpenID and OAuth with OpenID Connect

Update: Einar Solbakken has translated this post to Danish.

OpenID Connect

On Friday, David Recordon, one of the original authors of OpenID, released a single-page specification for OpenID Connect, a concept that I outlined on this blog in January before I joined Google.

I’m particularly excited about this early proposal because it builds on all the great progress that the community has made recently on a litany of technologies, including OAuth 2.0 and the link-based resource descriptor format (LRDD) and its emerging JSON-based variant (JRD).

But I’m most excited about OpenID Connect because it forces the OpenID community to evaluate the progress we’ve made over the last three years (OpenID 2.0 was introduced in 2007) and to think critically about where we go next, and how we get there, given what the market has indicated it wants.

Rearticulating the problem

When Brad Fitzpatrick first created OpenID, he was looking to solve a fairly mundane problem: develop a protocol that made it possible for a commenter to claim her comments on someone else’s blog. For the commenter, she had a way to vouch for her words; for the blog owner, he had a way to establish the authenticity of the comments left by his readers. Given this context, all that was required in the early days of OpenID was a stable way to uniquely identify people — gathering additional profile information wasn’t as necessary because blog commenting forms already asked for — and often required — that commenters supply their name and email address.

Thus the basic architecture of OpenID concerned itself with establishing identity across contexts (i.e. “Bob” from Context A is the same “Bob” found in Context B), rather than with profile portability. This focus lent itself to privacy-preserving anonymous and pseudonymous transactions where identity could be established without the need to divulge personally-identifying information, or without forcing you to collapse the boundaries of separate social contexts.

This feature of OpenID (called directed identity) enabled you to hold a single account at, say, yahoo.com, but sign in to third party sites using “non-correlatable identifiers”. That is, this feature made it possible to maintain discreet profiles for logging in to other sites across the web without needing a different password to manage each.

The ability to “select [the] OpenID identifier” that I want to share with stackoverflow.com is how this feature manifests on yahoo.com:

Yahoo - Select your OpenID identifier

The economics of user-centric identity

Features like directed identity, however, present several challenges for users and OpenID relying parties.

For users, these features complicate the sign in flow by introducing new interface surfaces (as seen above) and management tasks. They also increase the cognitive burden of registration by requiring a user to pick a profile (or create a new one) to use in a given context. Additionally, the ability to refrain from disclosing profile information when registering for a new service may seem economically advantageous to the user at the outset (“Aha! I refuse to tell you my name or email address!”) but results in unintended disadvantages over time.

That is, because OpenID users share less information with third parties, they are perceived as being “less valuable” than email-based registrants or users that connect to their Facebook or Twitter accounts.

Why? Simply put: OpenID, by design, favors the user rather than the relying party. In contrast, technologies like Facebook and Twitter Connect emphasize the benefits to relying parties. So while it might seem like an inconvenience to custom-tailor your personal privacy settings on Facebook, the liberal defaults are meant to make Facebook users’ accounts more valuable to relying parties than other, more privacy-preserving account configurations.

So, as Twitter and Facebook have grown in popularity and the number of sites willing to outsource their account management to them have increased, both OpenID users and providers find themselves in a predicament: if they continue to restrict the flow of data, the number of OpenID relying parties will diminish in favor of Facebook- and Twitter-Connected sites. If instead OpenID users become more liberal with the data that they are willing (and able) to share with third parties, they will still need to rally support from relying parties to be recognized as valuable users. Thus making more data available from OpenID users is the first essential step that we must take to regain our footing in the marketplace.

But it won’t be enough.

To overcome both the real and perceived economic disadvantage of supporting OpenID, we need to make adopting OpenID exceedingly simple, straight-forward, and economically advantageous — in real terms.

Why harmonizing “Connect” is important

I wrote my overview for OpenID Connect convinced that the “connect” verb (inherited from the Twitter and Facebook platforms) would help users distinguish between merely registering for a site and signing up for and sharing some data about themselves. Even though Facebook abandoned the “connect” brand at F8 this year, I’m still of the mind that the “connect” verb suits our purposes, even if it’s going to take several years to catch on in common usage.

In any case, if OpenID solves the problem of providing a stable and unique way to identify someone, then the “Connect” in OpenID Connect layers in the ability to access data on someone’s behalf (via conventional APIs like Portable Contacts or ActivityStreams).

It’s this assemblage of authentication and authorization technologies that the industry is calling out for — as evidenced by the success of Facebook and Twitter Connect and more recently, Messenger Connect from Microsoft and upstart efforts like Diaspora that cite OpenID among the technologies they intend to leverage. Without a common standard, each of these efforts is inventing its own custom-tailored solution, retarding industry-wide progress and delaying the development of next generation social applications.

Thus, by leveraging OAuth as the core of OpenID Connect, we can build on the consensus and momentum that has been achieved in the marketplace, and by weaving in a standard and much-simpler discovery mechanism, we can preserve the decentralized design of OpenID. Presuming that Facebook, Twitter, Google, and others all become OpenID Connect providers, that means that site operators can implement one connect API and interoperate with potentially dozens of providers with a single, well-understood open source stack of technologies.

Such an outcome would be good for relying parties (or “clients” in the parlance of Recordon’s proposal) as well as citizens of the web, who deserve a choice when it comes to entrusting a provider with their digital identity but are increasingly marginalized by “privacy-preserving technologies” that are not economically viable.

“Connect” also provides a convenient answer to the question of what kind of interface to present to the users who want to use their OpenID:

OpenID Connect

(Note that I also used the “connect” verb very intentionally in my social agent mockups for designing identity into the browser.)

If every site that supports third party authentication today added a “connect” button in place of their conventional “sign up” or “register” buttons and deployed a consistent user experience around picking a provider (some combination of NASCAR buttons and a type-anything email/URL field) that executed the OpenID Connect protocol, we’d be well along the path of decentralizing the social web, and restoring balance to the ecosystem.

What does OpenID stand for?

Of course, applying the OpenID brand to this solution isn’t something that I would do trivially, since the OpenID Foundation is the real authority for the trademark. However, at the foundation’s board meeting earlier this year at the OpenID Summit West, we unanimously decided to expand the scope of the OpenID Foundation’s mission to include advancing the technological underpinnings of internet identity in general, without regard for the existing OpenID technology.

This is a critical recasting of the role that OpenID and the OpenID Foundation plays in the ecosystem. Though there are other groups with similar mandates, the OpenID Foundation has decided to take on the internet identity opportunity as a general problem, rather than one narrowly scoped to disposable use cases.

In that light, it seems to me that we have come to a crossroads in the history of the foundation — however knowingly — and decided to take aggressive actions to advance the cause.

Without speaking for the foundation as a whole, I believe that it is essential that we are able to reconceive OpenID as the brand for decentralized digital identity. OpenID need not be thought of as merely an identity algorithm, but as a means for representing and conducting oneself online and across digital environments. Thus as the identity landscape undulates, the OpenID Foundation is in the position to articulate solutions that are not protocol-bound, but responsive to needs of the time, and able to adapt to and weather the shifting winds of technological progress.

After OpenID 2.0, OpenID Connect is the next significant reconceptualization of the technology that aims to meet the needs of a changing environment — one that is defined by the flow of data rather than by its suppression. It is in this context that I believe OpenID Connect can help usher forth the next evolution in digital identity technologies, building on the simplicity of OAuth 2.0 and the decentralized architecture of OpenID.

12 thoughts on “Two tastes better together: Combining OpenID and OAuth with OpenID Connect”

  1. Authorization and authentication is the holy grail of identity on the web.

    Hopefully your post means that Google is onboard, so that we smaller developers “can implement one connect API and interoperate with potentially dozens of providers with a single, well-understood open source stack of technologies.”

  2. I’m definitely interested in seeing how this iteration of OpenID developers.

    However, I’m not so sure about the value you place on the verb “connect.” Users already have a good idea what’s mean by links to “signup,” “register,” or “login,” but how will users interpret a button to “Connect”? Connect what? Does that mean create a new account, does it already require one? “Connect” doesn’t have the same historical context that “signup” or “register” has.

    I’m only speculating, but I wonder if this is why Facebook saw higher engagement for “Login with Facebook” than “Connect with Facebook” buttons – part of their motivation for the branding change.

  3. There’s no way OpenID is going to present sites with as much user info as Facebook. Instead of hoping that adoption will catch on despite this, perhaps we could say that OpenID draws a different class of user? Demographics are important, and if it’s true that geeks are preferentially quitting Facebook or using OpenIDs, then that is the value to the site who’ll adopt OpenID connect.

    Of course, if you can figure out how to market and brand a open distributed service, there’s more than a few people who’ll be interested in that.

  4. I think any new iteration of OpenID where (more) privacy is given up is wrong and unnecessary.

    OpenID in its current incarnation failed to get traction because of the anti-pattern of using urls instead of email addresses/usernames not because of a lack of personal information identifiers.

    Without having looking into it further, something like webfinger in conjunction with oauth could be used to do the email to openid url lookup. Hence, retain the password pattern while still doing what openid was originally intended to do.

  5. Thanks Chris, thoughtful as usual.

    What seems to be missing from conversations around OpenID, and from the digital identity conversation in general, is a stated position on what we think online identity should look like in 2020. We should clarify not only the vision for the social web, but why normals should support that vision.

    Given that most of the designers/coders/entrepreneurs involved in OpenID come from a similar pedigree, it may be useful to take a step back and consider the assumptions embedded in the digital details –

    why does choice matter? why does privacy matter? why should online interaction mimic the offline world? is the goal to augment or replace offline connections, or are watching the creation of a new category of connection?

    In trying to explain the vision for OpenID over the last few months I’ve had a hard time 1) locating it and 2) explaining WHY it matters. We ought to spend as much time on simplicity and clarity of vision as simplicity and clarity of button.

    Jake

  6. @theharmonyguy:

    Now sure if this kinda answers your question, but here is how Chris describes Connect:

    Connect = Profile (identity, accounts, profiles) + Relationships (followers, friends, contacts) + Content (posts, photos, videos, links) + Activity (poked, bought, shared, blogged)

  7. I agree with nm. I value my privacy a lot (see my fake e-mail), and OpenID delivers on that part – much more than Facebook or others.

    And while we’re at it: why hasn’t anyone specified e-mail like IDs for OpenID yet? You put in me@yahoo.com and the website heads over to yahoo to present you (a usarname-pre-filled) login screen.

Comments are closed.