<div>>> <span style="border-collapse:collapse">I wrote up a quick sketch of an idea in response to Eric's description of the problem with the OAuth flow for desktop/mobile apps:</span></div>
<div><br></div><div>Thanks Chris for following up on that issue. I'll keep on saying it until I am blue in the face, but we have to get the industry to change the way rich-client apps are built, or federated login is going to continue to be a very tough sell.</div>
<div><br></div><div>We have considered an approach along the lines of what you described. In particular, s<span class="Apple-style-span" style="font-family: Arial; ">ome
devices want to access a user's data, but do not have the ability to
display a full web browser. For example, think of devices like an
AppleTV, or a fridge that displays
your family photos from Flickr/Picassa.</span></div><div>
<p></p><p></p>
<p><span style="font-size:10pt;font-family:Arial;color:black">One
of Google's challenges is that Google exposes lots of APIs such as Photos, Health,
& Ads. So we want to allow the app to request access to just a
limited set of scopes. And for some of those scopes (like Health), we
even need the user to choose the access level and profile. <span class="Apple-style-span" style="border-collapse: collapse; font-family: arial; ">Many OAuth SPs (like FriendFeed), do not need to support that level of complexity, so in those cases the approach you described seems reasonable.</span></span></p>
<span style="font-size:10pt;font-family:Arial;color:black">For
Google, in the "fridge display private photos" example, our team had
suggested something like the following</span><span style="font-size:10pt;font-family:Arial;color:black"> </span>
<p><span style="font-size:10pt;font-family:Arial;color:black">1)
Device/app starts the OAuth dance and also requests a PIN from Google which Google
will associate with the OAuth request token<br></span></p>
<p><span style="font-size:10pt;font-family:Arial;color:black">2)
After the device/app gets the OAuth request token, it tells the user (or its manual tells the user) to visit a
short URL (like fridgephoto/register). The device then displays the PIN they will need, and
says to come back and click a button on the device when they are told</span></p>
<p><span style="font-size:10pt;font-family:Arial;color:black">3) The
user goes to a web browser on another device, like their personal computer, and
opens that site. The site is a static HTML page that gives some introductory
help text, and a link to Google's site to do the authorization.</span></p>
<p><span style="font-size:10pt;font-family:Arial;color:black">4)
When the user clicks the link, they are sent to Google with the URLs parameters
for the scopes that device/app needs, and a Continue URL back to that site, as well as a URL
param indicating the user has a PIN </span></p>
<p><span style="font-size:10pt;font-family:Arial;color:black">5)
They are then sent through the standard Google OAuth approval process.
If the user has not yet logged in, then they will need to do so (and
this might involve a redirection to a SAML/OpenID IDP and/or use of a
strong auth mechanism like a USB token)<br></span></p><p><span style="font-size:10pt;font-family:Arial;color:black">5)
Once the user is logged in, they see a standard Google OAuth approval page with information about the
claimed app, the scopes, and any advanced controls such as to pick access level
or a profile. Assuming the user clicks okay, they are then asked to enter
the PIN. Google confirms the PIN is a valid outstanding one, and then the
user is redirected to the continueURL (like fridgephoto/authzdone)</span></p>
<p><span style="font-size:10pt;font-family:Arial;color:black">6)
That device/app's site displays a static HTML file that tells the user to
go back to the device/app and click a button to indicate they finished the approval process<br></span></p>
<p><span style="font-size:10pt;font-family:Arial;color:black">7)
The user click's the continue button on the device/app</span></p>
<p><span style="font-size:10pt;font-family:Arial;color:black">8)
The device/app then finishes the OAuth dance</span></p>
<p><span style="font-size:10pt;font-family:Arial;color:black">Note
that an "evil" hacker could request a lot of PINs from Google, and hope that a
user mistakenly types a PIN that is associated with a "hackers" request token,
thereby giving access to the user's data. <span> </span><span>As an extra layer
of security, we can send the user an E-mail after an OAuth approval that used a
PIN, with the "claimed identity" of the app, and provide a
single link the user can click to deactivate that OAuth token. If the
user does more then one approval for the same claimed app in a short period of
time, then on the OAuth approval page we might even give a warning that the
previous one might have been "hijacked" and give them an easily way
to deactivate any recent OAuth tokens issued to the same claimed app.</span></span></p></div><br><br><div class="gmail_quote">On Thu, Oct 30, 2008 at 4:32 PM, Chris Messina <span dir="ltr"><<a href="mailto:chris.messina@gmail.com" target="_blank">chris.messina@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I wrote up a quick sketch of an idea in response to Eric's description<br>
of the problem with the OAuth flow for desktop/mobile apps:<br>
<br>
<a href="http://factoryjoe.com/blog/2008/10/30/lightweight-access-pins-a-modest-proposal-for-enabling-openid-in-desktop-and-mobile-apps/" target="_blank">http://factoryjoe.com/blog/2008/10/30/lightweight-access-pins-a-modest-proposal-for-enabling-openid-in-desktop-and-mobile-apps/</a><br>
<br>
Food for thought. Comments welcome!<br>
<br>
Chris<br>
<div><br>
On Fri, Oct 31, 2008 at 7:20 AM, David Recordon <<a href="mailto:drecordon@sixapart.com" target="_blank">drecordon@sixapart.com</a>> wrote:<br>
> From<br>
> <a href="http://google-code-updates.blogspot.com/2008/10/moving-another-step-closer-to-single.html" target="_blank">http://google-code-updates.blogspot.com/2008/10/moving-another-step-closer-to-single.html</a><br>
><br>
> Moving another step closer to single-sign on<br>
><br>
> Thursday, October 30, 2008<br>
><br>
> By Eric Sachs, Google Security Team<br>
<br>
</div><div>> One other question that a lot of people asked yesterday is when a large<br>
> provider like Google will become a relying party. There is one big problem<br>
> that stands in the way of doing that, but fortunately it is more of a<br>
> technology problem than a usability issue. That problem is that rich-client<br>
> apps (desktop apps and mobile apps) are hard-coded to ask a user for their<br>
> username and password. As an example, all Google rich-client apps would<br>
> break if we supported federated login for our consumer users, and in fact<br>
> they do break for the large number of our enterprise E-mail<br>
> outsourcing customers who run their own identity provider, and for which<br>
> Google is a relying party today. This problem with rich-client apps also<br>
> affects other sites like Plaxo who are already relying parties.<br>
</div>> _______________________________________________<br>
> general mailing list<br>
> <a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
> <a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
><br>
><br>
<br>
<br>
<br>
--<br>
Chris Messina<br>
Citizen-Participant &<br>
Open Technology Advocate-at-Large<br>
<a href="http://factoryjoe.com" target="_blank">factoryjoe.com</a> # <a href="http://diso-project.org" target="_blank">diso-project.org</a><br>
<a href="http://citizenagency.com" target="_blank">citizenagency.com</a> # <a href="http://vidoop.com" target="_blank">vidoop.com</a><br>
This email is: [ ] bloggable [X] ask first [ ] private<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
</blockquote></div><br>