Difference between OpenID and OAuth

Surprisingly there's much confusion between "OpenID" and "OAuth". People tend to use them as interchangeable terms or consider OAuth as a kind of a new and improved version of OpenID. In fact they are quite different things. I decided to write down my explanation to have a place to link to in the future.

This post is not about which one of those is "better", or "evil", or "dead". Just bare facts.

Summary

OpenID allows a site to make sure that its user owns some personal URL (of a site, blog, profile). This fact is sufficient to use this unique URL to recognize the user next time he logs into the site. That's it. Everything else — registering accounts, obtaining emails and other data, permitting any activity on the site — is up to the site itself. In other words, OpenID is a pure authentication mechanism: you know who's come upon your site and you can do with this knowledge whatever you like.

OAuth allows a program (on the web or local) to obtain from a user certain rights to use a particular API. The rights are denoted with a token whose nature is not defined: it can be the same for different users or the same user can be granted different tokens at different times. The only thing guaranteed is that upon presenting the token to the service the program will be able to perform certain actions on it. In other words, OAuth is a pure authorization mechanism: you have certain rights but you can't infer their owner's identity.

Here's an analogy. OpenID is your driver's license: it says who you are but it doesn't imply you're going to drive a car whenever you're asked of your ID. OAuth is you car's key: a valet can drive your car with them but he doesn't need to know your name to do it.

Signing into sites

Given the summary above, OpenID seems to be the natural technology for implementing signing into sites with external accounts. And due to non-defined token properties such thing as "sign in with OAuth" shouldn't even be possible. However it's the OAuth that Twitter and Facebook use for their ubiquitous "Sign in" buttons. How's that?

Well, while both Twitter and Facebook use OAuth in their respective implementations they have absolutely nothing in common in everything else. The roles of protocols are as follows:

• OAuth provides sites with authorization to use Twitter/Facebook API
• it's those APIs that provide then authentication since both of them give out some user identifying information

Another analogy. "Sign in with OAuth" is a key from a car that happen to have owner's name on the insurance in the glove box.

It's important to understand that since authentication is done through proprietary API it's not a "sign in with OAuth" but rather a "sign in with Twitter/Facebook". One practical implication of this is that it's not possible to have a generic OAuth sign-in library that will work with any arbitrary site like Twitter and Facebook.

Unless…

OpenID Connect

Unless you standardize an open authentication API instead of relying on proprietary ones. Then the idea of a generalized OAuth-backed sign-in could work. And there was an attempt to do exactly that — OpenID Connect. It separates the core idea of OpenID — open authentication — from the protocol of exchanging keys replacing it with OAuth. It also defines accompanying things like discovery mechanism that OAuth lacks.

However OpenID Connect is not used anywhere in practice. And the reason to that is a completely different topic.