Nathan, This looks very useful. Regarding auto-detection techniques, I think the page misses one, which would be for the installed application to register a custom protocol handler and provide for the callback URL to use that custom protocol, thereby relaunching the application. If I'm not mistaken, this is how some iPhone applications handle the OAuth flow.
You may also want to amend #3 (using browser extensions) to point out that this is one way to redirect control back to an Adobe AIR application by using a Flash embed on the page at the callback URL (which would have to be hosted separately) to relaunch the AIR application to continue to process. I haven't thought much about whether these techniques work under the new draft, but nothing that would derail them comes to mind immediately. Ethan On Sun, May 17, 2009 at 2:48 AM, Nathan Beach <nbe...@google.com> wrote: > Google has enhanced our OAuth approval flow to significantly improve the > user experience for installed applications that use OAuth to access our > GData APIs. > Previously, the only way installed applications could use OAuth to access > our GData APIs was to register a domain > name<http://code.google.com/apis/accounts/docs/RegistrationForWebAppsAuto.html>and > then use the consumer key and secret associated with that domain name. > This meant that anyone could impersonate OAuth requests as if they came from > that domain name because that domain name's consumer secret had to be baked > into the application--and thus is effectively public. > > Additionally, using the consumer key and secret for a domain name when an > installed application is the OAuth consumer results in rather puzzling > language on the OAuth approval page. Specifically, the user would be told > that a website--e.g., www.example.com--is asking for access to data when, as > far as the user is concerned, it is the installed application requesting > access. > > We have updated our OAuth approval flow to address these two issues. > > First, to address the fact that any consumer secret used in an installed > application cannot remain secret, we are publishing a consumer key and > secret pair that is specifically intended for use with installed > applications: > > Consumer key: anonymous > Consumer secret: anonymous > > > Anyone may use this key/secret pair without registering their installed > application. For this reason, we display a prominent warning message > informing users that we are unable to verify the identity of the application > requesting access to the data. (This serves a similar purpose as the warning > message we display when a user is authorizing access for a request made via > unregistered AuthSub.) > > Second, to address the puzzling language on the OAuth approval page that > results when the consumer key and secret of a domain name are used in an > installed application, we now permit installed applications to specify their > display name by sending the xoauth_displayname parameter when fetching the > request token. We use that parameter to display to the user the claimed name > of the application requesting data. > > The attached screenshot.png file shows the OAuth approval page resulting > from the xoauth_displayname parameter being set to "Photo Editor". (Note > that installed applications to which a user has granted access are not yet > listed on our OAuth revocation page, but that will be added in a couple > weeks.) > > Before we make an official announcement about this, we want your input > about the approach we're using to improve the user experience of installed > applications using OAuth. There will be a number of Googlers at the upcoming > Internet Identity Workshop <http://www.internetidentityworkshop.com/>, and > we will definitely have an opportunity to discuss this at IIW. If you are > using a different approach to improve the user experience of OAuth for > installed applications, we want to hear from you. Additionally, if you begin > experimenting with this approach in an installed application (i.e., if you > try using anonymous/anonymous with xoauth_displayname), we want to hear from > you. One easy way to begin experimenting with this approach is to use the > OAuth > Playground <http://www.googlecodesamples.com/oauth_playground/>. (To set > the xoauth_displayname parameter, check the "Advanced" box before fetching > the request token.) > > The attached OAuthForInstalledApps.png file shows the step-by-step flow of > this approach to OAuth with installed applications. One of the more > difficult issues with developing installed applications that use OAuth is > auto-detecting when the user has granted approval in the web browser--and > thus when the application can exchange its request token for an access > token. (This is step 8 in the attached flow diagram.) To spur use of OAuth > by installed applications, we published several techniques installed > applications can use to auto-detect > approval<http://sites.google.com/site/oauthgoog/oauth-practices/auto-detecting-approval> > of > the access request by the user. Please let us know any approaches you can > think of to accomplish this. > > Nathan Beach > Associate Product Manager, Google Security > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
