{"id":651,"date":"2008-10-29T20:20:40","date_gmt":"2008-10-29T20:20:40","guid":{"rendered":"http:\/\/neosmart.net\/blog\/2008\/google-doesnt-use-openid\/"},"modified":"2013-08-26T18:18:44","modified_gmt":"2013-08-26T23:18:44","slug":"google-doesnt-use-openid","status":"publish","type":"post","link":"https:\/\/neosmart.net\/blog\/google-doesnt-use-openid\/","title":{"rendered":"Google Abandons Standards, Forks OpenID"},"content":{"rendered":"

A couple of hours ago, the Google Security Team posted an article claiming that Google\u2019s made the switch to OpenID<\/a>, joining Yahoo!<\/a> and Microsoft<\/a> in the ranks OpenID providers.<\/p>\n

But it looks like someone may have been a bit to hasty to pull that switch (perhaps itching to get some of the limelight<\/a> Microsoft has been receiving for adding OpenID to all Live ID accounts just the day before yesterday)\u2026 because whatever it is that Google has released support for, it sure as hell isn\u2019t OpenID, as they even so kindly point out in their OpenID developer documentation<\/a><\/em> (that media outlets certainly won\u2019t be reading):<\/p>\n

\n
    \n
  1. The web application asks the end user to log in by offering a set of log-in options, including Google. <\/li>\n
  2. The user selects the "Sign in with Google" option. <\/li>\n
  3. The web application sends a "discovery" request to Google to get information on the Google authentication endpoint. This is a departure from the process outlined in OpenID 1.0.<\/strong> [Emphasis added]<\/li>\n
  4. Google returns an XRDS document, which contains endpoint address. <\/li>\n
  5. The web application sends a login authentication request to the Google endpoint address. <\/li>\n
  6. This action redirects the user to a Google Federated Login page.\n<\/p>\n<\/li>\n<\/ol>\n<\/blockquote>\n

    As Google points out, this isn\u2019t OpenID. This is something that Google cooked up that resembles<\/em> OpenID masquerading as OpenID since that\u2019s what people want to see \u2013 and that\u2019s what Microsoft announced just the day before.<\/p>\n

    It\u2019s not just a \u201cdeparture\u201d from OpenID, it\u2019s a whole new standard.<\/p>\n

    <\/p>\n

    With OpenID, the user memorizes a web URI, and provides it to the sites he or she would like to sign in to. The site then POSTs an OpenID request to that URI where the OpenID backend server proceeds to perform the requested authentication.<\/p>\n

    In Google\u2019s version of the OpenID \u201cstandard,\u201d users would enter their @gmail.com email addresses in the OpenID login box on OpenID-enabled sites, who would then detect that a Google email was entered. The server then requests permission from Google to use<\/em> the OpenID standard in the first place by POSTing an XML document to Google\u2019s \u201cOpenID\u201d servers. If Google decides it\u2019ll accept the request from the server, it\u2019ll return an XML document back to the site in question that contains a link to the actual<\/em> OpenID URI for the email account in question.<\/p>\n

    This is shown quite clearly in the following image (courtesy of Google, ironically):<\/p>\n

    <\/p>\n

    As you can see, steps 3 & 4 are not part of OpenID<\/strong> and leave Google\u2019s implementation of OpenID, such as it is, incompatible with everyone else.<\/p>\n

    Google actually mentions this in passing:<\/p>\n

    \n

    Starting today, we are providing limited access to an API for an OpenID identity provider that is based on<\/strong> the user experience research of the OpenID community. Websites can now allow Google Account users to login to their website by using the OpenID protocol. We hope the continued evolution of both the technical features of OpenID<\/strong>, as well as the improvements in user experience. will lead to a solution that can be widely deployed for federated login. One of the companies using this new service<\/strong> is www.zoho.com.<\/p>\n<\/blockquote>\n

    Eric Sachs, author of the blog post in question<\/a>, doesn\u2019t actually come out and say, but he does come very close.<\/p>\n

    Basically, Google has rewritten OpenID. Not only is it not exactly the same as the current OpenID protocol, it\u2019s so different that existing OpenID relying parties won\u2019t be able to use it. Only a handful of \u201cpartner sites\u201d have been updated to understand Google\u2019s perverted version of the OpenID standard, and anyone else hoping to authenticate via \u201cOpenID\u201d to Google\u2019s servers will need to do the same.<\/p>\n

    But OpenID is an open, community-based standard. Stabbing them in the back by creating an incompatible standard \u201cbased on\u201d the same technology and masquerading under the same name isn\u2019t the way to go. Google may have the best interests of decentralized authentication in mind, and perhaps even the better protocol to boot; but this is no way to prove a point.<\/p>\n

    OpenID is on tenterhooks as it is, and cannot withstand any more efforts to splinter its adoption. Never mind the fact that almost all the big names adopting OpenID are joining only as providers and not as relying parties (rendering the whole basis of OpenID useless) \u2013 now even the provider side of things is chaos.<\/p>\n

    Thanks, Google. Good to see you\u2019re still doing the whole \u201cDo no evil\u201d thing, the community really appreciates this kind of approach to improving de facto standards and pushing decentralized authentication!<\/p>\n","protected":false},"excerpt":{"rendered":"

    A couple of hours ago, the Google Security Team posted an article claiming that Google\u2019s made the switch to OpenID, joining Yahoo! and Microsoft in the ranks OpenID providers. But it looks like someone may have been a bit to … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[686,23,22,673,685,12,188,21],"class_list":["post-651","post","type-post","status-publish","format-standard","hentry","category-software","tag-authentication","tag-google","tag-microsoft","tag-oauth","tag-openid","tag-security","tag-standards","tag-yahoo"],"aioseo_notices":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p4xDa-av","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/posts\/651","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/comments?post=651"}],"version-history":[{"count":1,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/posts\/651\/revisions"}],"predecessor-version":[{"id":2561,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/posts\/651\/revisions\/2561"}],"wp:attachment":[{"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/media?parent=651"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/categories?post=651"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/neosmart.net\/blog\/wp-json\/wp\/v2\/tags?post=651"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}