Wandering Thoughts archives

2017-08-04

The problem with distributed authentication systems for big sites

In the comments on my entry on 'sign in with your Google/Facebook' authentication, people wished for a distributed cross-site web authentication system (of which there have been some number) but then lamented that nobody significant adopted any of them (as Anton Eliasson put it). As it happens, I think that there are good reasons for this disinterest by big sites beyond the obvious business ones.

The simple version is that when you allow your users to authenticate themselves using another site you put part of their experience with you in the hands of someone else, along with part of their account security. If you are a big site, some noticeable amount of your users will choose badly; they will use sites that are not reliable, that do not stay online forever, or are not secure. When bad things happen, those users will be unable to use your site (or at least have a much harder time of it) or their accounts get hacked and exploited. You will inevitably have to spend some amount of engineering resources building systems to deal with this, and then some amount of user support resources on dealing with people who run into these problems and can't fix them themselves. On top of that, a fair number of these users will probably blame you for their problems, even though they are not your fault in one sense.

(In another sense the problems are your fault. It is up to you to design your website so that people can use it, and if people find themselves locked out, that is your fault for allowing it to happen.)

When you run your own authentication system and require your users to use it, you own the full experience. You're entirely responsible for making authentication work well, but in exchange you're self-contained; you don't have to hope that anyone else is up and working right. When you are big and heavily engineered and almost everyone else is smaller and less well engineered, you may rationally feel that you're going to do a much better job on average than they are, with less downtime and problems. And if there are problems, you can troubleshoot the entire system yourself; you have end to end ownership of all components.

(As a corollary, if you're in this situation the very last thing you want to see is a bunch of your users all relying on the same outside authentication provider. The more of your users rely on a single outside provider, the more of an impact there will be if that provider stops working right. If a quarter of your users decide to authenticate with Yahoo and one day Yahoo is sold and turns off their authentication, you have a big problem. Unfortunately it's pretty likely that users will concentrate this way.)

Small sites that rely on big sites for user authentication face many of the same issues, but both the odds and the tradeoffs are different. It's pretty unlikely that Google's or Facebook's authentication systems will be broadly unavailable or malfunctioning, for instance. You can also cover most of your potential users by supporting only a few carefully chosen outside authentication sources, instead of potentially having a huge number of small ones (with various degrees of bugs or differences in how they view, eg, the OAuth spec).

(I'm talking here strictly about authentication, not about accounts and identity. Any serious site must own its own account system, because you cannot count on other people to keep spammers and abusers out of your system. To put it one way, Facebook is not going to close someone's account because they were nasty on your site.)

Sidebar: The business reasons matter too

Let's not pretend that business considerations don't matter, because they do for any commercial organization. To put it one way, when you allow authentication to be outsourced, you don't entirely 'own' all of your customers or users. Instead some of them are basically loaned to you from their authentication sources, and those sources might some day decide to end that loan. In an extreme case, all you have for those users is 'user X on service Y', and once service Y cuts you off you have no way of re-establishing a connection with those people so they can come back to your service.

web/DistributedWebAuthProblem written at 02:04:08; Add Comment

By day for August 2017: 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 18 19 20 21 22 23; before August.

Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.