AccountChooser

This isn’t exactly a Google thing, but we’ve been putting a lot of work into it, and now it’s about ready to use. I think lots of sites should. Because it’s easy, private, secure, and reduces login pain.

AccountChooser is from the OpenID Foundation, with active input from lots of big tech companies. It’s not often that I’ve seen this sort of thing happen co-operatively; no discernable jostling or politics.

What You See · To demonstrate, I built this little app called FavColor that will save one fact about you: your favorite color. Its badge is this little rainbow thingie.

FavColor has a conventional sign-in page for people it knows and a conventional sign-up for those it doesn’t. It’s even got an identity management subsystem with a dorky little database of usernames and hashed passwords. But it also supports three popular ID providers: Facebook, Google, and Microsoft’s “live.com”.

When I point my browser at favcolor.net, I don’t see a FavColor landing page, but this:

It’s my AccountChooser; a list of accounts that I’ve used to log in to something or other in this browser. When I pick one, it’ll try to log me into FavColor with that account.

[If you visit FavColor.net, you’ll probably just see its landing page, because you probably don’t have any AccountChooser history built up. Read on to find out how to fix that.]

When AccountChooser’s there and everything goes well, click on an entry and—Pop!—you’re logged in. Maybe even if you didn’t have an account there before. Depending on how things are set up, you might have an IDP like Facebook or Google asking (first time only) if it’s OK to use that address to log into FavColor. If you get unlucky, the IDP might even ask you to log in with your password again. But most times, it’s Pop! and you’re in.

That’s all there is to it.

The Most Important Thing To Know · Even though the address bar reads “accountchooser.com”, none of your data ever leaves the browser. This stuff all lives in HTML5 local storage; the accountchooser site is just a static source of HTML, JavaScript, and CSS.

AccountChooser doesn’t remember or log what sites it helped people sign into, and its logs aren’t read by anyone.

Here’s how contained it is: If you have a bunch of entries in your AccountChooser and you switch from IE to Firefox, or Safari to Chrome, you’ve lost ’em. Because all the storage is local, and the stuff being stored isn’t all that sensitive, there’s no crypto or anything involved.

Also Important · The identities in your AccountChooser don’t need to be tied to any specific IDP, or to any IDP at all. They don’t even need to be real email addresses; they’re just things that you’ve used as usernames for some site or another, and have agreed to save in AccountChooser.

Run a Site? · If so, you should maybe use AccountChooser; here’s why:

1. It reduces sign-in friction and (more important) sign-up friction. In particular for a site that’s trying to grow, that’s a big deal.

2. It reduces the probability that people accidentally log into the expenses system with their BitTorrent-hacking personal account.

3. It’s humane; people on the Net visibly shudder when they show up at yet another site’s idiosyncratic landing page. Get past the sign-in tax and straight into the value-added part of your service.

4. You want to know who the people visiting you are, but if you can get out of the usernames-and-passwords business, why wouldn’t you? IDPs are a good thing, and AccountChooser helps with several of the problems you’ll probably have in integrating with them.

For Geeks · It’s all done with a chunk of Apache2-licensed JavaScript called ac.js. There is marketing over at accountchooser.net, with links to integration and API documentation; I particularly like this video.

You can also visit the working group site at ac.openid.net for a look further under the hood. Although the API is frozen, the documentation is a moving target and is being actively updated.

Without replicating the detailed integration guide, here’s what you have to do to add AccountChooser to your own sites:

1. Invoke ac.js in your landing page, and it’ll redirect to AccountChooser.

2. When a human clicks on an entry, ac.js will HTTP-POST back to an endpoint you have to provide, telling you what they clicked on (potentially including email, IDP, photo-link, and display-name). You have to return a chunk of JSON telling AccountChooser to send them to your sign-in page, your sign-up page, or an IDP.

3. When you get someone signed in, you have to redirect to AccountChooser one last time, telling it what info they signed in with: As many of email, IDP, photo link, and display-name as you have.

   Most times, if they came in from AccountChooser, this is a fast no-op. But if this is the first time they’ve logged in with this info, they’ll be prompted if they want to add it to AccountChooser. Which, by the way, is how AccountChooser, which starts empty, gets loaded up.

   Whether or not any update happens, ac.js finishes up by sending the browser back to your site’s home page.

There is no Step 4!

Once again: reducing login pain is a Good Thing For The Internet and for the people who use it. Have I mentioned recently that I have a terrific job?

---

---

Contributions

---