On May 17, 12:48 am, Nathan Beach <[email protected]> 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....>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--isasking 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...>
> 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
>
> screenshot.png
> 66KViewDownload
>
> OAuthForInstalledApps.png
> 78KViewDownload
Thanks, Nathan. I guess given the (vulnerable) nature of installed
apps with OAuth, this should help.
-cheers,
Manish
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"OAuth" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~----------~----~----~----~------~----~------~--~---
