While the news that Google is now an OpenID Provider was generally welcomed, a common chorus decrying their support (along with others large OPs like Yahoo, Microsoft and others) at best as half-hearted, at worst as ruining OpenID has revealed a significant barrier to such large providers becoming relying parties (even beyond usability).
Eric Sachs (Google Security Team) writes:
One other question that a lot of people asked yesterday is when a large provider like Google will become a relying party. There is one big problem that stands in the way of doing that, but fortunately it is more of a technology problem than a usability issue. That problem is that rich-client apps (desktop apps and mobile apps) are hard-coded to ask a user for their username and password. As an example, all Google rich-client apps would break if we supported federated login for our consumer users, and in fact they do break for the large number of our enterprise E-mail outsourcing customers who run their own identity provider, and for which Google is a relying party today. This problem with rich-client apps also affects other sites like Plaxo who are already relying parties.
Fortunately there is a solution, and it was developed specifically because Ma.gnolia ran into this problem when it became an OpenID relying party. The result, nine months in the making, was OAuth. Eric even recognizes this:
We need standard open-source components on as many platforms as possible to enable those rich-client apps to support OAuth. That includes a lot more platforms then just Windows and Mac. The harder part is mobile devices (Blackberry, Symbian, Windows Mobile, iPhone, and yes even Android), and other Internet connected devices like Tivos, Apple TVs, Playstations, etc. that have rich-client apps that ask users for their passwords to access services like Youtube, Google photos, etc. If we build these components, they will be useful not only to Google, but also to any other relying parties which have rich-client apps or exposes APIs, and it will also help enterprise SaaS vendors like Salesforce.
As I’ve been thinking about this problem, I’ve come to see as an intermediate approach to full-on delegated authorization a simpler, perhaps more familiar approach that would be relatively easy to implement given common interface patterns today. For comparison, Pownce’s iPhone app originally used out-of-band browser-based authentication, leading to a swarm of user criticism resulting in a compromised solution that required embedding a web browser in the app. Less than ideal.
In my proposal, rather than ask for a user’s password, an easier-to-remember OP-issued numerical PIN would be used to authenticate requests. Better is that this approach is already supported in OAuth, it’s just not widely used yet (though is similar to how Flickr authorizes mobile clients).
The basic concept is that you’d have one password (or other strong authentication method) for your primary OpenID account and you’d have one (or more) PINs that you would use to access your account remotely — perhaps in limited risk scenarios or where (again) the full browser-based OAuth flow is not possible or warranted.
Although I initially opposed FriendFeed’s use of Remote Keys, I now think that there’s some merit to this approach, as long as the underlying mechanism uses standard OAuth calls.
There are plenty of holes in this approach, but insomuch as it enables an existing pattern to be phased out gently, I think it offers at least the foundation of an idea that could be useful. It also could be used as a counter-balance to some of the current thinking on federated login flows with OAuth.
Consider these three sign in boxes for comparison:
- Traditional Password
- Lightweight PIN access
- Full OAuth
Thoughts welcome.
Factory Joe 
hmm why not an SMS message that tells the user what the application is trying to do and asks to reply back typing “OK” to approve. Why another “secret” PIN that the users need to remember in addition to their passwords.
If we do not want to make some users pay for the SMS, we can use email (most devices provide access to your email) or even an automated phone call to ask for user confirmation.
We talked about this at the last IIW as a possible extension to OAuth but we never wrote anything down.
@Praveen: Yeah, one of my ideas that I’ve suggested before is that when an OpenID request is made, a smart OP will detect that you’re in a mobile-like (limited) environment and send you a PIN via SMS, or, as you suggested, ask you to confirm (via a Y or N response) a particular action.
The reason for the PIN is that the latency of SMS can really kill a sign on experience… not to mention that not everyone can provide SMS-based messages.
As for sending a token via email, in the case of Gmail/webmail, if you don’t have tabs, you’re still exiting your flow, in which case you might as well do full on OAuth.
One other aspect of the PIN idea is that you could set up, say, more than one PIN… each with different types of pre-set permissions… like “read private data”, “delete one item”, “send me email”, etc… If you keep your PINs simple, this could work, though it is a bit of a lead-user/uber-geek idea.
I’m probably treading old ground here, but this looks like it’s only a few steps away from a bluetooth-like model where you “pair” your device with your account using a *one-time* PIN issued by the consumer out of band. You’d go to the site in a browser and request a PIN, and then enter that into the mobile app. It can then use the PIN to request an OAuth token.
The dependency on a browser is still there, of course. I’m not sure how much traction this approach would get in practice.
As a user, I think I’d prefer getting an SMS (even if it takes me away from the interface) because then I know that only I can get the code from the SP. For a hacker to even attempt to guess my PIN, they’d need to know that I was attempting to authenticate. If I get an SMS every time someone tries to authorize access to my account I can take action because I know it’s happening.
In the use case above, a hacker could attempt to guess the lightweight PIN. In this case, there is no out-of-band notification to the user. So there is less likely hood that the user would know they are being hacked. I suppose that could be mitigated with SP notification via email, SP rate-limiting and allowing only one attempt per un-authorized request token.
For devices like phones with only a numeric keypad, and set-top-box units like TiVo, I’d still prefer a mechanism that used my laptop to set it up. I realize there are a lot of people where the only connected device they have is a cell-phone so this approach doesn’t work for everyone.
Maybe we need a couple of “best practices” for this kind of UX and then allow the apps to determine which one is best for their environment.
Is the “problem” with full OAuth just that people get confused when the browser opens? Is this a problem on the desktop as well, or only on the phones for some reason?
Don’t think it’s a problem on the desktop as this is something the users are already used to – take a look the way the web versions (flash) of Yahoo Messenger or Google Talk work.
@Martin: Yep, just like pairing your account session to your actual account. Or at least the flow would be similar. However, it breaks when you have to open a browser window — that said, a PIN might be easier to type/remember on a phone, so the PIN concept might still be useful.
@George: I do think that we need to be able to address the limitations of multiple devices, some of which won’t or can’t be upgraded and will continue to rely on a username and some shared secret (aka password or PIN) to handle authentication. The point of the PIN is to address those situations — so that you can still use your favorite identifier without using your main account password.
A premise here of the PIN model is that certain “low risk” actions could be performed with the PIN — but other actions — resetting your password, deleting your account, publishing content (maybe) would not be allowed. This would be determined on a service by service basis (probably by the service provider itself or in collaboration with the user — “allow these actions to be performed with only PIN authentication”).
@Stephen: it’s not just user confusion. It’s that you need to address the situation where you have an identifier (an OpenID) but no password to access your account. A PIN approach would be similar to what 37 Signals uses in Basecamp feeds, etc.
Chris,
an interesting idea that still has one serious problem; it assumes the mobile (or desktop) login isn’t the first usage.
SMS pincode latency is (imo) less of a problem than bouncing users in and out of browsers.
I think if Oauth is going to work, it has to stop assuming there’s a browser in the loop. That or accept it’s not a general purpose model.
Chris-this is a great discussion to get started! There are lots of cases where you just *can’t* pop up a web browser during auth (many mobile phones, set top boxes, etc.) so you need *some* form of “direct auth” for accounts, and if those accounts are RP accounts, today you’re screwed. Something like a PIN + direct-auth-api to the OP seems like the only solution, though it won’t work for 2-factor/strong-auth situations.
But even if everyone agreed to offer such APIs, you’re left with a UI problem: all of these UIs currently ask users for “username/password” or “email/password” since today most sites have their own login database. I think we need some creative solutions for how/when to ask for “OpenID/PIN” and what form that takes. There’s also the issue of how/when users know to get a PIN, and do they remember it, and how temporary/hackable/etc it is.
But this problem is not going away, and it’s going to prevent many large services from becoming RPs if we don’t solve it, so let’s keep this going, and let’s have a session on this at IIW.
Thanks, js