Subject: Re: [OAUTH-WG] native app support (was: Next draft)

From: Brian Eaton <[email-masked]>
Date: Tue, 6 Jul 2010 14:23:27 -0700

On Tue, Jun 22, 2010 at 11:00 PM, Luke Shepard <[email-masked]> wrote:
> Two points:
>
> 1/ I agree that it can be onerous for clients to host web pages. It's not a matter of expense but of complexity.
>
> BUT
>
> 2/ As we discussed previously in our in-person meeting, this should be handled by a different endpoint, and not be the responsibility for the provider. If Google wishes to support this for their desktop apps, then it should provide an endpoint that handles the OAuth response and puts it in the <title>. I can say that Facebook has no interest in supporting this hack on the server side, but clients that want it can use their own html file that does it for them.
>
> For example, for Javascript web apps it is a pain to host a cross-domain receiver file. So we host one on behalf of developers (called xd_proxy.php). But it is not part of our server-side logic.
>
> If you want to write a spec for that, then great, but the <title> hack does not belong in the main spec.

Luke -

A couple of questions for you.

Question #1: In another thread, you mentioned "We require either
pre-registration of the callback URL, or that the app uses a standard
redirect URL on Facebook.com (which could only be used by a desktop
app)."

It sounds like both Google and Facebook have needed to provide a
standard way for desktop applications to receive callback URLs, and
that we've both opted to do so by hosting a page on our own site.

What approach does your callback URL use for passing the authorization
code down to the desktop app?

And do you see value in standardizing that approach?

(We settled on the <title> hack because it was very portable.  But
it's pretty ugly, and we'd love something better.)

Question #2: most of the installed app developers we talk to ask how
they can provide some sort of display name for their application, both
on the approval page and on the revocation page.  Do you see the same
requirement, and if so how do you meet it?

Cheers,
Brian

---

From: Luke Shepard <[email-masked]>
Date: Tue, 6 Jul 2010 17:38:40 -0700

Responses below.

> code down to the desktop app?

We suggest developers use the user-agent flow, and retrieve the access token after the fragment in the URL. We include links for .NET, Adobe Air, and Objective C libraries. We haven't really run into issues with desktop apps for which this is not possible (to my knowledge).

http://developers.facebook.com/docs/authentication/desktop

> And do you see value in standardizing that approach?

You mentioned that there were desktop apps that aren't able to read the URL values, but which can read the <title> value of apps - I know both Yahoo and Google mentioned this. If you can show that this type of app is a common scenario, then I can see some value in making it widespread. For now I haven't really seen a lot of examples of this in the wild such that it's worth standardizing.

One way to standardize this would be to host a file on a common domain - initially probably something like google.com, and then later perhaps a file on oauth.org or somewhere. It could use Javascript or server-side logic to intercept the access token and display it in the <title>. Providers would need to accept redirect_uri values that contain that well known URL. 

But it is much easier for a provider to just say "Oh, you're using oauth.org/desktoptitleauth.html? okay" than it is to implement the desktop title trick themselves.

> requirement, and if so how do you meet it?

We don't allow unregistered applications. When an app registers their client_id, they can specify a name and multiple sizes of icons.