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:
- Visit the mobile Brightkite site.
- If it’s not provided on the homepage, click “Sign in with OpenID” (remember, this doesn’t exist today).
- Enter your OpenID and hit “Login”.
- 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).
- Once you receive the SMS from Brightkite, you return to the login flow and enter the key.
- 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.
- As before, we start by visiting the mobile Brightkite site.
- If it’s not provided on the homepage, we click “Sign in with OpenID”.
- Enter your OpenID and hit “Login”.
- This time however, we’re going to bounce over your OpenID provider where one of three things could happen:
- 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.
- If your identity provider recognizes both your OpenID URL and the relying party URL as a mobile site (i.brightkite.com), 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 Brightkite.com as you. To confirm this request, use this token: [12345].”
- 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.
- As before, once you receive the SMS from Brightkite, you return to the login flow and enter the key.
- 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.
Thoughts/counter-proposals/arguments?
Factory Joe 
OpenID is perfect for mobile sites, because registering and logging in is a HUGE PITA, even for devices with keyboards. Any process that reduces keystrokes would be a huge usability win.
Instead of sending the user’s cell phone number to the RP, it may be better for the OP to provide an OAuth protected messaging API to allow the RP to send SMS (or email) to the user without having to know the user’s email address or phone number. Users who do not want to receive any more messages from the RP can just revoke the OAuth token.
Additionally, the OP can manage the user’s SMS preferences, for instance, users can set limits for the number of SMSes that can be sent to their phone per month in order to avoid getting overcharged by their wireless carrier. Users could also configure their OP to not send SMSes while the user is likely to be asleep.
Hook me up with one of those brightkite invites, Chris.
Sounds like it’s just about time for me to finish up my next generation twauth. I guess I could add an API to allow sites to do non-OpenID-flow authentication of twitter accounts like you suggest.
Looking forward to see your progress!
Nice article! If we make the assumption that most modern mobile handsets recognise a url in an sms body (as i think they do) we can eliminate the cut/paste involved in getting the key from the sms to the webform by including the key in a url inside an sms, which can then be visited to authenticate the mobile user. You’d have to ensure your url length was under the maximum supported, which i guess would vary between handsets.
I couldn’t agree more with Allen’s comment that today’s mobile login experiences are in dire need of improvement.
I like the fact we can rely on the phone number as such a unique and personal token. My thinking even goes so far that there could be be a DNS-like system one day for associating mobile phone numbers with an OpenID record — I could use it as an alias to my OpenID Url, on a phone or anywhere. (My DNS record could be updated/overwritten by my OpenID provider whenever I successfully claim ownership of the number)
But back to mobile login flows: from the user’s point of view, I would strongly favor a solution that doesn’t require a break in medium, i.e. that doesn’t switch from the mobile browser to my SMS inbox and back. Copy/Paste is a poorly supported paradigm on phones and if you ever tried to remember a phone number while switching between two mobile screens, you know how cognitively unpleasant it can be. Even if it’s just a short code, it doesn’t feel right to rely on the user (and their short-term memory) to do the transfer. What am I missing that makes mobile OpenID so different from web-based authentication? If we come to agree that your OpenID should be responsible for verifying and keeping your phone number on record (I certainly think this makes good sense), then the flow could stay entirely web-based or not? Certainly, OpenID providers would need to support mobile login UIs (and possibly mobile numeric PIN-based password) for an optimal experience but that could be a matter of time given the increasing adoption of mobile web services.
Thanks for leading the way on this much-needed discussion, Chris.
Hi Chris,
I just came agross to your interessting blog about mobile OpenId. I am new to the OpenID topic but have some experience in mobile.
In my opinion the success of mobile openID will depend mainly on usability.
You have at least to
1. type in your OpenID each time you access a website
2. type in the SMS (basically very secure but probably not suitable for mass market.
Too many clicks and to much to type on the small displays was (among the slow speed) one of the causes of the the flop of WAP Services at the beginning of this century.
The number of inputs and clicks should be reduced.
Here my idea:
1. could be solved by “proactive HTTP header-based Discovery”:
You pass the openid.server along with in every HTTP request (it is not your personal ID so you don’t care…).
Then the Relying Party can redirect you automatically to the OP server (so step 1 is automatic).
Your mobile browser would need to allow setting the name of your open id server in the HTTP Headers (e.g. x-openid.server: http://www.myopenid.com/server).
(Btw. Firefox already allows setting HTTP headers… so it would make surfing on your PC also more confortable 😉
Alternatively you could configure the mobile browser to use some HTTP Forward Proxy which would insert the HTTP header on your behalf.
2. Once you are redirected to the OP, this can use permanent cookies to “identify” you and present you directly the password field.
Of course this may require an extension of the Open ID standard protocol because any RP willing to provide access to mobile would have to read the HTTP header from the request, but if there is enough interesst around…
There is already a HTML-Based Discovery, so why not an HTTP Header based Discovery?
What do you think?
Adrian