Signed, sealed, and delivered as of February 26th. Better than that: In high-volume production at Google and Deutsche Telekom for a while now. Based on OAuth 2, which has been frozen since 2012. Not perfect, but I’d call it one of the safer technology deployment bets you can make right now.
Let’s say “OIDC” for short, “OpenID Connect” is kind of klunky.
The Basics · OIDC specifies a handful of OAuth 2.0 flows; the most important result is an ID Token, which I wrote about last year; one of my favorite pieces of standards-ware in years. An ID Token is an assertion, signed by an IDP, that some particular person was authenticated for the purposes of some particular app. It’s straightforward and cheap to validate, and suitable for shipping around the network (assuming HTTPS of course, it’s not encrypted) from client to server to server to wherever. Very handy.
It drives Google+ Sign-In and if you really want to sling JSON at HTTP end-points we offer that too. A large number of people use it every day at Google and Deutsche Telekom; you know, the pink-“T” company, not a small operation. One reason it’s getting this kind of deployment is that the OpenID Foundation ran an aggressive interop-testing program and established that yeah, this pretty much just works.
History · The story starts with the original OpenID work, which had two premises: First, anyone should be able to use any IDP. Second, everyone should be identified by a URI.
That second premise turned out to be wrong; ordinary human beings apparently don’t think of themselves as Resources that need Uniform Identifiers, or some such.
The next chapter was OpenID 2, with a much more fully-thought-through security story. It got pretty good deployment at some big Internet names including Google and Yahoo. But there was a lot of grumbling from ordinary developers who had trouble getting the crypto right, the symptom being weird hard-to-diagnose interop failures.
In another Enterprisey universe the XML-based SAML identity protocol is in production at lots of companies (including for Google apps, which work fine with SAML IDPs). But SAML just isn’t Internet-flavored and is unlikely to grow much past its current footprint.
Which brings us to OpenID Connect.
The big deal · OIDC assumes you’ll identify people using email addresses, which isn’t perfect but app-builders like it; and bothers people less than URIs. It’s got a good security story, but so did its predecessors. You can build a good sign-in User Experience with it, but that’s not new either.
I think the big deal with OIDC is the developer experience; it’s pretty easy to implement from scratch, where by “from scratch” I mean “JSON messages over HTTP with a crypto library to check signatures”.
I suspect that in the near/medium term that story gets even better as OIDC oozes into commercial identity products and open-source libraries; but it’s already pretty good.
I speak from experience here, having implemented the OIDC web-app flows myself (in Ruby/Sinatra if it matters). I did this starting in 2012 before OIDC was fully cooked, and had to hand-integrate with a few server implementations that weren’t 100% compatible. It still wasn’t hard.
I think this really matters. Things that are straightforward to deploy and Just Work get deployed. Things that aren’t don’t.
One gripe · OIDC has browser semantics wired pretty deeply. In particular, redirects; the assumption is that you can redirect to one URI to get user approval and do authentication, then to another to get a token, and so on. Which is fine unless you’re in a native app (desktop, iOS, Android) which doesn’t have redirects.
Of course, you can always spin up a browser to help you do that stuff; in particular both iOS and Android make that pretty easy. But you have to choose between an embedded WebView and calling out to the system browser; either way you lose some UX control.
Android solves this, if you’re using Google accounts, by providing a decent API you can call; it just spits out an ID Token and you’re off to the races. And on iOS, if it’s Google accounts you’re after, the Google+ client library takes care of you there too.
But things would be better if there were a nice portable general-purpose get-me-an-ID-token API available for arbitrary IDP accounts, cross-platform. The OpenID Foundation is working on this; good for them.
Discovery and the ecosystem · Another important virtue of OIDC is that it’s carefully designed to let more or less any client interoperate with more or less any IDP, automatically. It goes like this:
You start with someone’s email address. Using WebFinger (or other heuristics) you have a good chance of figuring out who the right IDP is to log them in with.
Once you know which IDP you’re talking to, you there’s a Discovery document, a chunk of JSON you can fetch from a well-known location that will tell you how to get your app registered with that IDP and what the endpoints are for authentication and tokens and so on.
Walk through the OIDC protocol and hey-presto, you’re all signed in!
It’s actually better than that; the protocol is set up so you can be your own IDP; in fact, you can set things up so that your mobile device is in effect an IDP for you, letting you get signed in with no big-Internet-company being involved at all.
This is about as fully-thought-through a realization of the original OpenID dream as one can reasonably imagine.
Only there’s a problem; nothing to do with technology though. Suppose you’re building an app and decide to use OIDC, so you do a presentation to your management about how wonderful this is going to be: Start with an email address and execute the protocol and there you go, painless secure login!
Except for, at this point, somebody in management says “better run that by Legal” and someone in Legal says “let me get this straight, you’re gonna let anyone sign into our app with any old IDP at all, wherever it is in the world, whoever it is?” And just possibly Legal is not going to be crazy about this idea.
So I suspect the first wave of OIDC deployments are going to involve whitelists; apps will explicitly specify which IDPs they’re interested in relying on.
An interesting next-step is meta-whitelists; add a level of indirection and imagine something like an academic consortium that blesses a list of IDPs acceptable for login at their institutions. This just adds a step to the login process; when you figure out which IDP you want to use, you call out to some intermediary to see if they meet your criteria.
The long-term dream · Right now, when you say “IDP”, in practice this tends to mean “Facebook or Google”. And maybe Twitter. Which sort of sucks; I don’t know what the right number of IDPs in the world is, but I’m pretty sure it’s bigger than five.
And with OIDC, we have the technology we need to support a wide-open ecosystem of IDPs, where individuals should be able to pick who they want to authenticate them. This is good! Now we just have to figure out the policy issues.
Contributions
Comment feed for ongoing:
From: Janne (Mar 02 2014, at 16:51)
One thought:when you say "email address", to what extent does it have to be an actual, useable address? Is actual email delivery ever needed, or could I simply set up my "myserver.jp" at home to be and idp, and implicitly accept an "janne@myserver.jp" identity for this purpose without ever actually running a mail server?
[link]
From: Sarah (Mar 02 2014, at 18:03)
"imagine something like an academic consortium that blesses a list of IDPs acceptable for login at their institutions."
e.g., Shibboleth IDP InCommon
http://www.incommon.org/
[link]
From: Pete Forman (Mar 03 2014, at 00:40)
I signed up for Twitter a while ago but rarely tweet. What was the risk if someone hacked it? That they'd tweet something interesting? But now that little used account might be used to get into a service of value. (BTW I did turn on two factor when it became available.)
[link]
From: Andrew Ducker (Mar 03 2014, at 02:15)
When it comes to retrieving a verified user's email address could something like BrowserID be useful?
[link]
From: W^L+ (Mar 03 2014, at 05:40)
I hope the new OpenID address is just a webfinger and not necessarily a real, functioning e-mail address. People lose access to old e-mail addresses and open new ones all the time. That would make the new, OAuth based OpenID Connect as fragile as the old versions were.
One of the problems with identifying with URIs was fragility. At one point, $BIG_OPENID_PROVIDER required a full HTTP path. Then, they required a full HTTPS path. Finally, they allowed a generic path (HTTPS) that they'd fix on login.
Answering phone calls because $BIG_OPENID_PROVIDER decided to change their implementation of OpenID was not fun. Eventually, I had to turn it off.
[link]
From: Dan Fabulich (Mar 03 2014, at 11:46)
I don't get it. I thought OpenID Connect would prompt the user for an email address so we could detect which IDP to use, then correspond with the IDP to authenticate the user via a pop-up.
Google+ Sign In isn't like that at all; it's a button users click to login with Google (and only Google). If G+ Sign In is OIDC, then I don't know what OIDC is at all.
Maybe the point is that G+ Sign In uses industry-standard ID tokens, but nobody cares about that, because G+ Sign In is supposed to be a black box anyway.
[link]
From: Jacob C. (Mar 03 2014, at 13:05)
Tim, I think you might be overstating the centrality of the email address as an identifier, since that only comes in to play if WebFinger is used during discovery, and discovery itself is not a mandatory feature of OpenID Connect.
[link]