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 