Is Facebook's client-side authentication flow using redirect_uri is borken?

If I understand correctly, to make API calls from my desktop application开发者_JAVA技巧 (let's call it from now and on 'client' as in the OAuth2 standard) I need to obtain an access_token which is an identifier that combines both the application id and the user's, who's data I want to access, id ('resource owner').

Following client flow on the authentication guide (developers.facebook.com/docs/authentication/) I understand that I need to send request to h**ps://www.facebook.com/dialog/oauth?client_id=YOUR_APP_ID&redirect_uri=http://example.com&response_type=token. In result, the page will be redirected to h**p://example.com/#access_token=XXX. If the client is a pure desktop app, then redirect_uri can be h**p://www.facebook.com/connect/login_success.html. Since the client owns the web control the access_token can be easily extracted from the redirected address.

The client side flow consists of 3 OAuth steps:

1. User authentication, if resource owner is not logged in to Facebook, a dialog, asking for Facebook credentials, will be shown. If the resource owner is logged in, the session will be authenticated using the cookie on Facebook's servers. Security - CHECK V !
2. App authorization, if resource owner didn't give permission for the app yet, the permission dialog will ask from the resource owner to grant permissions to the app, if the resource owner previously grated all needed permission, the permissions dialog will not be shown. Security - CHECK V!
3. App authentication - Now, here is where it gets sticky. The guide says: "App authentication is handled by verifying that the redirect_uri is in the same domain as the Site URL configured in the Developer App". Security - In my opinion - FAIL!

Why do I think that the last step is a security fail? First of all, both app id and redirect_uri are public information that anyone can obtain. Second of all, redirect_uri can be h**p://www.facebook.com/connect/login_success.html.

Let's look at the following scenario. A desktop app, EVE, shows to the user a web control where the user logs in to facebook and grants EVE some basic permissions. Resource owner has no reason to suspect anything. Next, EVE hides the the web control, and tries to load on it h**ps://www.facebook.com/dialog/oauth?client_id=OTHER_APP_ID&redirect_uri=http://www.facebook.com/connect/login_success.html&response_type=token. The app can try and load this url with the most popular facebook apps application ids. The app will get the Success message if the user previously authorized the OTHER_APP, since both login dialog and permissions dialog will not be shown. This will give EVE an access_token to access all resources of the resource owner that the resource owner granted to OTHER_APP and not to EVE.

So, is this a security hole? Did I miss something in the follow?

(UPDATE)

Clearly in a case of a desktop app, the security issues are irrelevant since the app has already the username and the facebook session and even the username and password, it can do anything with the users account.

(UPDATE) For JavaScript apps that run in a web browser redirect_uri actually works! (See answer and comments by hnrt).

CURRENT QUESTION: The only remaining mystery is how the client authentication works on iPhone and Android apps? Is the security whole is similar to the one when using a desktop application? Is there some difference in jailbreaked iPhones or rooted Androids?

Cheers!

If I understood correctly, your scenario would require that the user has already authenticated himself for the other apps using the same web control that EVE can use to talk to Facebook. If that is the case, then there are already much bigger security problems :) EVE could just hijack the whole session and all its authentication tokens.

[UPDATE] Regarding Javascript applications, same origin policy prevents EVE from accessing the reply of the /dialog/oauth?client_id=OTHER_APP request. The only way to access the data is to wait at redirect_uri and parse the redirected request. Here the "site url"-protection kicks in.

I am not sure how things work in iPhone and Android applications, but I would be really surprised if their web controls allowed access to the authentication data (=cookies) of other applications.