The OpenID mobile experience, part II

In January, I wrote about the “OpenID mobile experience” lamenting that it sucked and asking for positive examples of identity providers who got it right. Well, I didn’t get a whole lot of examples, but Ian McKellar (Songbird) did get inspired to hack something together called Twauth, which serves as the foundation for a flow that I’m going to articulate now.

The foundation of Ian’s idea is this:

My initial approach was to offer an OpenID URL for phone numbers and use an SMS message containing a one-time password to verify that the person attempting to log in had access to that mobile phone. Unfortunately there’s no free web service for sending SMSes, so did the next best thing and built it on top of Twitter.

Extending this, I have two variations of this proposal, that could work today. I will be using Brightkite as the example service, since they currently do not support OpenID but should and are at least interested. So, given that, here’s a proposal for how they could make it happen.

Single-site mobile sign-in with OpenID

The first approach requires no change to the OpenID protocol, but actually leaves out OpenID altogether beyond the initial association, which may or may not be a good idea, security-wise. Regardless, no one says you can’t do what I’m about to propose, so here we go.

I already have an account with Brightkite, and use a traditional username and password to sign in. Let’s assume that Brightkite adds support for OpenID, and allows creating new accounts with OpenIDs or allows existing members to associate an OpenID with their account — by verifying against the identity provider — not just adding a URL to their account (as Beanstalk used to do!).

Let’s also assume that you’ve associated a phone number with your account. (Now, while you could arguably just use your phone number for this flow, the point is to associate an OpenID with your account and then use it to sign in later.)

So, once you’ve associated your OpenID and your phone number your account:

  1. Visit the mobile Brightkite site.
  2. If it’s not provided on the homepage, click “Sign in with OpenID” (remember, this doesn’t exist today).
  3. Enter your OpenID and hit “Login”.
  4. Since you’re on the mobile site, we’ll assume that you’re indicating to Brightkite that you want to use a mobile-friendly flow to authenticate. Since, Brightkite has already associated a verified phone number with your OpenID, they simply send an SMS to that number with a key (probably 5 numerical digits).
  5. Once you receive the SMS from Brightkite, you return to the login flow and enter the key.
  6. If you provide the correct key, Brightkite should log you in successfully, since you’ve proven that you have control of the phone that’s associated with the OpenID you provided.

The key to this flow is that you have verified both your phone number and your OpenID, and so essentially you’re transitively substituting an OpenID URL for your phone number. Is this OpenID? Well, insomuch as you can use your OpenID identifier to sign in on both the desktop (where the full roundtrip happens) and on your mobile device, I think it’s at least compatible in the interim.

So why not just use your phone number to sign in? Well, you could, but as I’ll describe in the next flow, there might be a way for OpenID providers to do a better job with the mobile experience, and so starting here and training people to use their OpenID URL as opposed to a phone number to sign in to websites (and mobile experiences) seems like a good idea.

Roundtrip mobile sign-in with OpenID

Now, this entire flow is OAuth territory, but for the sake of discussion, I’m going to talk about the conceptual flow of OpenID. I recommend that anyone who wants to implement this flow actually look into using OAuth to support this mobile flow.

In this flow, we start with the similar presumptions except that instead of storing the mobile number with Brightkite, we’re going to store it with the OpenID provider.

  1. As before, we start by visiting the mobile Brightkite site.
  2. If it’s not provided on the homepage, we click “Sign in with OpenID”.
  3. Enter your OpenID and hit “Login”.
  4. This time however, we’re going to bounce over your OpenID provider where one of three things could happen:
    1. If your OpenID provider has a pre-defined mobile flow, or if you’re using directed identity (as Yahoo does) you’ll have to use the standard sign in procedure. This is how things are today.
    2. If your identity provider recognizes both your OpenID URL and the relying party URL as a mobile site (, it should immediately issue a token (like a five-digit numerical value) to Brightkite and send it (via SMS) to your mobile device. If you can provide that same token to Brightkite, Brightkite should successfully sign you in since you’ve proven that your identity provider knows that you’re trying to authenticate. In this flow, you wouldn’t see your identity provider; instead you would likely receive a text message that said “Someone is trying to sign in to as you. To confirm this request, use this token: [12345].”
    3. A slight variation to the previous step would be for the relying party (Brightkite) to indicate that it’s requesting a mobile flow in its original request, if available. This could be as simple as appending “?mobile=true” as a parameter hint to help the OpenID provider use a mobile-friendly authentication dance, rather than trying to recognize the relying party as a mobile site.
  5. As before, once you receive the SMS from Brightkite, you return to the login flow and enter the key.
  6. If you provide the correct key, Brightkite should log you in successfully, since you’ve proven that you have control of your OpenID identity.

The major benefit to this approach is that you’re actually authenticating against your OpenID provider. Additionally 1) you never necessarily need to reveal your phone number to the relying party (say, if we weren’t talking about Brightkite) and 2) should you change your mobile number, you would only need to change it on the side of your identity provider, rather than on every site that offer a mobile version of their site, to continue to be able to authenticate with your OpenID URL.

Bonus: Twauth v0.2: using Twitter direct messages

Finally, should a service or identity provider not wish to send (or pay for) SMS’, the alternative would be to allow someone to associate their Twitter account, via the Twitter API, to their existing account (e.g. their Brightkite account) and then to receive direct messages with the private tokens. The problem with this approach is that it uses Twitter, which may not be reliable, and that it also exposes tokens, via the Twitter API, to any other third-party services that can read your direct messages (basically any other Twitter app that asks for your Twitter account credentials).

Still, for testing purposes, Twitter could be a useful intermediary.