OpenID for authentication [LWN.net]

Please consider subscribing to LWN
Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.

December 7, 2016

This article was contributed by Tom Yates

I've just registered on "yet another web site", which meant another scramble for a username that's not already in use, another randomly-generated and highly-unmemorable password, and another email address provided for account recovery in the event that it all goes wrong. Along with my flying car and jetpack, I'd rather hoped the 21st century would bring a better way of managing my identity on the internet; in 2005 it did just that with the release of the OpenID standard for distributed authentication. Sadly, OpenID has remained a fringe player in this field.

How it doesn't work now

We've all experienced this registration pain: the multiple permutations of our preferred username, trying to find a variant that we can remember which no-one has already taken, and the generation of yet another nonce password, which our browser will have to remember for us. Need I mention the issues of either re-entering that password for storage on other browsers we use, or the use of some centralized storage system that's either local to a trusted device whose loss will be a near-disaster, or is stored in someone else's cloud, with all the trust issues that involves? They also want an email address for recovery. Do I use my regular one, and risk them losing control of it, or even simply selling it to spammers? Or do I generate a one-time one, which my mail server then has to be configured to know about?

In any case, isn't username/password authentication a bit stale? Most banking web sites now require some variant of two-factor authentication (2FA); it's time this became standard practice. But if every site rolls its own 2FA, then my storage-of-random-credentials problem just got even bigger. The right way forward for most web sites is federated authentication: the site delegates the business of ensuring that I'm really me to some generally available third-party. This is now starting to happen, but unfortunately the two big players are Google and Facebook, and you don't have to wear a tinfoil hat not to want to give them information about every single web site you ever use.

Things can be better

Fortunately, in 2005, OpenID was created. This is a distributed authentication system that, in its simplest form, ties my identity to a URL of my choice. That URL uses some link tags in the header to nominate my OpenID authentication provider of choice. You can see this in the top of my OpenID identity URL, https://www.teaparty.net/:

 <html>
 <head>
 <link rel="openid.server" href="https://openid.yubico.com/server.php" />
 <link rel="openid.delegate" href="https://openid.yubico.com/server.php/idpage?user=vvgdbhcgutti" />
 </head>
 <body>
 Regular web page stuff...
 </body>
 </html>

The links specify to whom I delegate the business of authenticating me (openid.server), and how I identify myself to them (openid.delegate). Note that these are not set in stone; indeed, they're downright disposable. If my current delegate goes out of business, I lose trust in their ability to handle this securely and reliably, or I just forget how I authenticate to them and I can't raise their customer service department, thirty seconds with vi (or three minutes with emacs) can put a new delegate in place.

In fact, when one provider did fail, that's exactly what happened: I used Google to find OpenID providers, picked one I liked, registered with it, and changed my delegation links. If I were feeling particularly paranoid and wanted to run my own authentication provider, I could, but even if I choose not to, authentication stays very much in my control because of my ability to re-delegate with the touch of a text editor.

So when I approach an OpenID-capable web site to log in, things unfold as the diagram shows.

I go to the web site, and tell it I want to log in as my identity URL, https://www.teaparty.net/.
The web site retrieves https://www.teaparty.net/ from my webserver and parses those tags.
The web site contacts openid.yubico.com and POSTs a request to establish a shared secret using Diffie-Hellman key exchange (the protocol calls this "associating").
The web site sends my web browser off to openid.yubico.com to authenticate, as I specified in the delegate tag, using our pre-agreed method. The web site provides a nonce as part of this exchange.
Provided that I authenticate to its satisfaction, openid.yubico.com sends my browser back to the web site with a token that is provably from that provider, and which is intended for the web site as part of this particular authentication exchange. This is possible because of the shared secret set up in step three, and the nonce provided in step four.

Note that the OpenID protocol is silent on the question of how the authentication in step four is to be accomplished. I am expected to have set that up with openid.yubico.com as part of the process of registering with it as my delegated provider. Authentication could be via username and password. It could be via a complex 2FA routine, which is not a problem because I only need one such arrangement to access all of my OpenID-enabled web sites. It could even be by some baroque arrangement where I call them up, pass a Turing test, and submit a blood sample for DNA matching; timeouts might be an issue, but the protocol has no problem with a scheme like that.

Doing OpenID well requires a little diligence:

Ensure that your identity URL is served under HTTPS, with a properly-signed certificate, from a domain secured with DNSSEC. You can't force any given web site to check certificates and DNS signatures, but providing them makes life harder for attackers. It used to be expensive and painful to do these things, but between Let's Encrypt and the fairly widespread availability of DNSSEC, it's no longer either of those.
Your delegated authentication provider knows which web site is asking you to authenticate through it, and it should provide this information to you in step four. Make sure you check that it matches the web site you think you're authenticating to.
As you may have guessed from the URLs above, I use one of the slots on my YubiKey for one-time password authentication. Whatever you plump for, use something more robust than simple username/password authentication with your delegated authentication provider.

The OpenID protocol has also had some security issues. These have generally turned out to be implementation-dependent (and fixed by the implementation's authors) or can be sidestepped by the use of SSL/TLS throughout the authentication chain.

How's that working out?

Wikipedia claims that "there are over 1 billion OpenID enabled accounts on the Internet [...] and approximately 1,100,934 sites have integrated OpenID consumer support". Unfortunately, with the honorable exception of ServerFault, few of the sites I find myself logging into are in that 1,100,934. One reason for this does not reflect well on big web sites: when you go through the business of registering with a big site, they can ask you for all sorts of biographical information. You don't have to give it to them, but many people will without thinking about it, and this allows the big sites to target advertising more effectively, and thus make more money. If all they get is a naked URL, they know nothing about you; there is thus a considerable incentive to make you go through the pain of registration. It is true that Google and Facebook logins are becoming more commonly available, but as Facebook makes clear, it will provide data to any web site that uses Facebook as a federated authentication provider:

When a person logs into your app via Facebook Login you can access a subset of that person's data stored on Facebook

OpenID has been extended, with a newer version of the protocol, to OpenID Connect. This new version allows a web site not merely to authenticate the user but also "to obtain basic profile information about the end-user in an interoperable and REST-like manner". One might be forgiven for suspecting this was to help OpenID gain support with the big web site brigade by addressing the concerns above, but it need not affect us. The authentication provider cannot provide information it does not have; if you suspect that it's trying to acquire it, you can, again, always run your own authentication provider.

Some web sites shouldn't support OpenID, or indeed any distributed authentication scheme at all, because the actions that an authenticated user can perform are too significant to risk any unnecessary failures in the authentication chain. Bank web sites obviously come into this category, but, arguably, interactions with government (e.g. online tax return filing) do as well. However, excepting those, I would like every web site that uses accounts to support OpenID, and I'd settle for a few more every day. If you're putting up a project site, please consider looking around for an OpenID plugin for your site code, and enabling it.

Recently, Joseph Graham posted to the FSFE Fellowship mailing list, saying he'd created a small FluxBB site, https://www.freesoftwareuk.org.uk/, for free-software enthusiasts to chew the fat, arrange pub meets, and so on. I immediately asked him to add OpenID support, which he did. By his own account, he found a plugin with a little searching; installing it was a matter of downloading a ZIP file, putting it where the forum's software could find it, and enabling it via the forum administrative interface. It is true that the plugin has some shortcomings, and he intends to find a better alternative, or write his own, shortly, but getting off on the right foot was not particularly painful.

If you're of a mind to add it to your WordPress site, there is a plugin that permits authentication via OpenID both for commenters, and for login to the main site; installation instructions are linked from the above page, and do not look onerous. Drupal really seems to have gotten the idea; the project notes that "users can create Drupal accounts using their OpenID. This lowers the barrier to registration, which is good for the site, and offers convenience and security to the users". Drupal decided to burn the candle at both ends, by supporting OpenID not only as a client, to allow authentication to a Drupal instance via OpenID but also as a provider, in order to use a Drupal installation as a delegated authentication provider.

The OpenID project maintains a collection of libraries and developer tools, including Apache and PHP modules to allow sites to permit users to authenticate via OpenID, and implementations of authentication servers to run a delegated authentication provider. With this many options, it's surprisingly simple to use OpenID for authentication, and not much harder to support it. While 2017 is unlikely to bring me a flying car or a jetpack, with a little help from the internet it might yet bring me distributed, decentralized identity management.

Index entries for this article
Security	Authentication
Security	Identity management
GuestArticles	Yates, Tom

The LWN site is currently under high scraper load, so comment display has been suppressed for anonymous users. If you are a human, you may read the comments by clicking the button below:

Note: you can avoid this step in the future by logging into your LWN account.