Liminal Existence

Fixing Sign-in

Sign-in is tricky business, and it doesn’t get careful enough attention. The folly I’ve allowed myself on Poetica is to try to make things better. After all, identity (and consequently sign-in) was basically all I thought about for the few years before starting on Poetica, and I had some ideas I wanted to try out.

Tim Bray, who’s taken it upon himself to work on these problems for Google, has written up a post about Poetica’s, and has said some nice things. I wanted to write up some notes on how we think about the problem from an interaction design and technology standpoint, and what’s still missing from our approach. Hopefully, this conversation will inform and increase the chances for success of Tim’s hosted version (and corresponding open source project).

The general principle can be stated simply, in two parts: first, give users a trust-worthy way to identify themselves. Second, do so with as little information as possible, because users don’t want to (and simply can’t) remember things like passwords in a secure way.

The first part is solved by any number of readily available standards: OpenID, OAuth, SAML, Kerberos, and so on, to name just a few. We support as many as possible / practical, including proprietary variants. I use the PassportJS library to handle the protocol bits, and the number of approaches it offers are many.

The second part – creating a simple and consistent way to sign in while preserving user choice and preventing vendor lock-in – is, frankly, the hard bit. But it’s also easy – there’s just a lot of social inertia to overcome. To cut to the chase, we try really hard to take our user’s most memorable globally unique thing, the thing 99% of sites already use to identify users – their email address – and use that to sign them in without requiring a password or forcing them to remember information that is meaningless to them like “Identity Provider” or “Delegated Authentication”, like this:

  1. If the user already exists in our system, sign them in using the method they used last time.
  2. If not, try to discover an authentication provider using their email address:
    1. Webfinger, to allow user choice regardless of domain, in the future where everyone’s email address supports it, amiright?
    2. MX record – if the provider that hosts your email supports delegated authentication (for example, Google Apps for Domains / gmail), all drawn from an internal lookup table), then we use that.
    3. OpenID and so on (e.g., IndieAuth) discovery against the email address’s domain.
    4. I want to add support for Mozilla’s Persona for discovery, but haven’t gotten around to it yet as the spec has been in flux and I’m not sure it currently supports the bits we’d need.
  3. If we still can’t figure it out, and the user is new, we ask them to sign up using a provider of their choice. Currently we only support Google, Hotmail, Twitter, and Facebook as sign-in options at this step. This is the weakest part of our process, and one we’re actively working to improve.

Once we have their sign-in provider, we show the user a single “Sign In” button and send them over to approve the request (first time only). We open a pop-up for them to interact with their provider rather than just redirecting so that if they get scared or for any other reason close the authentication window, we can catch that and increase the amount of help and number of choices we offer them. Our current implementation of this isn’t great, and is the other main thing we’re working to improve.

Subsequent sign-ins are automatically redirected back with no user intervention. Even on the first sign-in, most often the user is already signed into their identity provider, so they don’t even need to type in a password. We don’t ask our users if they’ve signed up or not – our database already has that information, so on first sign-in, we take the user through the sign-up process automatically, showing them a tutorial and asking them for any additional information we need.

We’re in private beta right now, but the process has been working really well. There are still kinks, to be sure, but the beautiful thing as far as I’m concerned is that most users don’t even notice that they’re signing in – they just do, and then get down to using Poetica. Which is exactly what we should be aiming for (but often can’t acheive) with security systems. The two bits of negative feedback I’ve heard, always from very savvy users, are that it feels a bit too simple to be trusted (are they being phished? A valid criticism, but I’d argue we’re better on the phishing front than most other solutions) and that our “which provider?” fallback page kind of sucks (it does).

I’m looking forward to contributing to Tim’s project to bring this to more people, and I hope you’ll consider using this approach in future (and current) projects.