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.

FavColor badge

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:

AccountChooser at work

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

Comment feed for ongoing:Comments feed

From: Zellyn Hunter (Dec 04 2012, at 17:11)

FWIW, when I click "Log Out" on favcolor.net, I get asked to pick my account on accountchooser.com two to four times, briefly seeing flashes of "Welcome to FavColor... Please log in" in-between.

[link]

From: Nelson (Dec 04 2012, at 17:56)

Sounds great, thanks for the clear explanation and demo! I'm curious, how does this relate to BrowserID/Persona? Is it competitive, complementary, unrelated... ?

[link]

From: Eric A. Meyer (Dec 04 2012, at 19:50)

While I understand that reasons for the behavior, I dislike how this creates a sense of browser lock-in. A small sense, maybe, but it’s still there, and it bugs me. People already grouse when they have to change their password on their banking site. How likely are they to want to dump all of their account history and start over?

(And if course I realize that the vast, vast majority of people never change browsers. I am, as usual, an outlier. Grump grump grump.)

[link]

From: James Holderness (Dec 04 2012, at 20:46)

I haven't been following this sort of thing for a while, but I always thought one of the big selling points of OpenID was being able to set up your own provider - precisely so you wouldn't have rely on somone like Facebook or Google for all of your logins. I mean those are the companies I'd least want to have tracking every single thing I did on the web.

Is that just something you haven't setup your test app to support, or is AccountChooser limited by design to work with only those three providers and noone else?

[link]

From: Tim (Dec 04 2012, at 21:17)

James: From the piece: “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.”

[link]

From: James Henstridge (Dec 04 2012, at 22:06)

Is it actually possible to log in with anything other than username/password, Google, Live or Facebook?

I've got no Account Chooser history, and those are the only options it is providing me to register on FavColour. Is that by design, or is there some trick to use a different identity provider?

[link]

From: MP (Dec 04 2012, at 23:17)

Good questions, Jameses.

It is worrying that this is a demonstration of a technology coming from the _OpenID_ Foundation and apparently I cannot test it, on account of my _OpenID_ provider not being as equal as G, M or F.

Whether it is a technical limitation of AC (I guess it is not?) or just shows the expected use of it, it is not good.

[link]

From: Matěj Cepl (Dec 05 2012, at 01:27)

@Nelson

> I'm curious, how does this relate to BrowserID/Persona?

I think whole idea of the department Tim works for now is to kill anything resembling BrowserID (or OpenID in its original form).

I don't want to imply bad faith on Tim’s part, but I really don’t understand how he wants to square this circle. Working for one of the biggest collectors of personal identities on the web and securing individual privacy.

Notice that this demo from OpenID Foundation doesn't allow using OpenID. When I wondered over how it is possible, I stumbled upon http://dickhardt.org/2010/12/oidf-2010/ ... it seems OpenID Foundation is not our friend anymore. Sad.

[link]

From: Jacek Kopecky (Dec 05 2012, at 04:36)

Great idea, I guess. But: I log in with Google, store account in AC, sign off, next time I go there, I click on the account in AC and get stuck at gauth-login-redirect with "Redirecting". Firefox, Mac OSX.

Plus, for some reason I couldn't post this comment for some time.

Plus plus, please add the "contribute a comment" link also after all the comments.

[link]

From: Blaine Cook (Dec 05 2012, at 11:39)

I have to admit, I'm a little disappointed. I won't implement AccountChooser for my sites because I (and most other folks building websites that I know) am not going to give up control over the design of my site's sign in / login experience to the extent that AccountChooser demands.

When I tried to sign in to favcolor.net with two separate Google accounts, AccountChooser failed badly. Beyond design issues, website owners aren't going to be down with delegating that level of control to a third-party site that doesn't even work (and, all due respect, but I wouldn't trust the OpenID Foundation with my user's identities for a heartbeat).

I also think (as I've said early and often) that browser independence is important. I sometimes find myself needing to use someone else's computer or phone to sign in, as well as vice-versa. AccountChooser defaults to too much automatic machinery, and will lead to people leaving accounts signed in on devices where the sign-in was meant to be temporary.

Further, having people blindly click accounts means that they need to remember and read, rather than just remember, the account that they use to sign in to a given site. My approach to that is to ask the user for their email address, something they hopefully remember, and doing the hard work of figuring out how to authenticate them myself. I don't depend on OpenID, LiveID, Persona, or any FutureID, but instead support them all. If I want to fall back to passwords, I can do that at my leisure, and my interface has no confusing options. In fact, the only "bug" with my workflow as far as I'm concerned is that Google and other identity providers (aside from Persona) give me no way to ask for a specific user (Google did until recently, but recently disabled the parameter that made it work).

Is there any research that suggests that anyone but desperate enterprise sites with captive users will actually use this?

[link]

From: Thomas (Dec 05 2012, at 14:20)

Your choice of favorite color to demo is incredibly ironic because RJ Pittman (the guy who was mentioned in the same story as you when you were hired by Google ( http://binged.it/TG3gyF ) is literally (no metaphorically) color blind. So what about people who are color blind, what other approaches could you take with OpenID?

[link]

From: AlastairC (Dec 06 2012, at 04:35)

I like the concept, but there seem to be a few bugs at the moment.

I tried favcolor.net with MS Live and Facebook, and with both I get stuck on a re-direct page (e.g. https://favcolor.net/fbauth-redirect... Title: "Updating Accountchooser", no content).

Also, even with two different accounts ready for use I can't see the initial screenshot in the post?

Also, the link to the JS is broken.

Anything that makes it easier for websites to use federated logins is good, hopefully it will be easier to implement that it appears to be here!

[link]

From: Daniel Serodio (Dec 06 2012, at 05:37)

The concept seems nice, but "IDP" (as in "Redirecting to your IDP") is a very technical term, and shouldn't be presented to the user.

Also, it seems favcolor.net is broken. The first time I went there and clicked on the Google icon, it showed a "Updating AccountChooser" mostly blank page. If I hit Reload on this page I get a 400 Bad Request error.

Then, if I go to http://favcolor.net/ again, I'm already signed in. Couldn't get it to show me the AccountChooser "dialog" in any way.

[link]

From: Tim (Dec 06 2012, at 14:26)

I'm using a previous version of AccountChooser on my site. But it doesn't work with Google Chrome Frame - https://developers.google.com/chrome/chrome-frame ( I want to be able to have my site work on IE browsers ). Has integration with this and other tools been worked out?

Thanks

Tim

[link]

From: Pete Forman (Dec 07 2012, at 01:06)

In order to see the demo site I had to accept a security warning: the name on the certificate for code.jquery.com does not match the server name.

[link]

author · Dad · software · colophon · rights

November 28, 2012
· Technology (77 fragments)
· · Identity (41 more)

By .

I am an employee
of Amazon.com, but
the opinions expressed here
are my own, and no other party
necessarily agrees with them.

A full disclosure of my
professional interests is
on the author page.