Moving another step closer to single-sign on
By Eric Sachs, Google Security
TeamYesterday we
announced
one step we took to help increase adoption of single-sign on across websites on the Internet.
For more details, you can watch
today's episode of
thesocialweb.tv which covers the launch. While we announced that we would initially
provide limited access to our OpenID IDP to make sure it was working properly, we were
delighted to see that the number of sites that registered to receive access was significantly
more than we had expected. So instead of having our engineers spend time manually maintaining
that list of registered sites, we are now taking another step further and removing that
restriction so any site can use the API.
That registration requirement
also led to some confusion because users wanted to be able to use existing websites that
accept OpenID 2.0 compliant logins by simply entering "gmail.com" (or in some cases their full
E-mail address) into the login boxes on those websites. Normally what would happen after a
user typed gmail.com is that the relying party website would look for a special type of file
(XRDS) on the gmail.com servers that would check if Gmail run an OpenID identity provider. For
yesterday's launch, we specifically chose not to publish that special XRDS file on gmail.com
because if we had published the file, users would have received an error at Google if the
website they were trying to log into had not registered with us. Now that we have removed the
registration requirement, we will work on pushing that XRDS file as quickly as possible. Once
the XRDS file is live, end-users should be able to use the service by typing gmail.com in the
OpenID field of any login box that supports OpenID 2.0, similar to how Yahoo users can type
yahoo.com or their Yahoo E-mail address. (In the meantime, if you feel really geeky, you can
type "https://www.google.com/accounts/o8/id" into an OpenID 2.0 compliant login box and see
the
directed
identity workflow in action.)
However, as we we noted in the
Designing a
Login User Interface section of our documentation, we do not place any requirements
on the design of a federated login box on a relying party website. There are many approaches
used by websites today, and the community is still experimenting with new approaches.
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.
Google is committed to working on this
problem. If community members also want to help in this area, please take a look at our
research on combining
rich-client apps with federated login which was discussed at the recent
UX summit
and discussed further
in a
blog post here. A key thing to notice is that this research is about another open
source technology called
OAuth, and is
agnostic to the particular federated login technology used, i.e. SAML or OpenID. It is also
agnostic to the type of strong authentication method (if any) that is used to authenticate the
user.
To further increase the adoption of federated login, 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 the community works together to build these components, they will be
useful not only to Google, but also to any other relying parties that have rich-client apps or
that expose APIs, and it will also help enterprise SaaS vendors like Salesforce.
If you want to help further these efforts, join the
OpenID and
OAuth mailing lists and tell people which platform
you are targeting in case others want to help. For example, Mike Malone from Pownce did some
work a few months ago to use OAuth on an iPhone and
described how he
got it working. And just yesterday another member of the open source community, Sean Sullivan,
built a working OAuth enabled rich-client app for Android and
posted the open source
code.
