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.
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.
and if you really want to sling JSON at HTTP end-points
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.
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
I think this really matters. Things that are straightforward to deploy and
Just Work get deployed. Things that aren’t don’t.
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
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
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
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
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
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