If I understand correctly, to make API calls from my desktop application (let him call now on the “client”, as in the OAuth2 standard), I need to get access_token, which is an identifier that combines both the application identifier and user data, which I want to access, id ("resource owner").
The following client thread in the authentication guide ( developers.facebook.com/docs/authentication/ ) I understand that I need to send a request in h ** ps: //www.facebook.com/dialog/oauth? Client_id = YOUR_APP_ID & redirect_uri = http: //example.com&response_type=token. As a result, the page will be redirected to h ** p: //example.com/#access_token=XXX. If the client is a clean desktop application, then redirect_uri may be h ** p: //www.facebook.com/connect/login_success.html. Since the client has web control, access_token can be easily retrieved from the redirected address.
The client side flow consists of three OAuth steps:
- User authentication, if the owner of the resource is not registered on Facebook, a dialog box asking for credentials for Facebook will be displayed. If the owner of the resource is registered, the session will be authenticated using cookies on Facebook servers. Security - CHECK V!
- Administration of the application, if the owner of the resource has not yet given permission for the application, the permission dialog will ask the owner of the resource to provide permissions for the application, if the owner of the resource has previously allowed all the necessary permissions, the dialog box with the rights will not be displayed. Security - CHECK V!
- Application Authentication Now, this is where it gets sticky. The manual says: "Application authentication is performed by verifying that redirect_uri is in the same domain as the site URL configured in the developer's application." Security - in my opinion - FAULT !
Why do I think the last step is a security failure? First of all, both the application id and redirect_uri are publicly available information that anyone can get. Secondly, redirect_uri can be h ** p: //www.facebook.com/connect/login_success.html.
Let's look at the following scenario. The EVE desktop application shows the user a web control in which the user logs into facebook and provides EVE with some basic permissions. The owner of the resource has no reason to suspect anything. Then EVE hides the web control and tries to download h ** ps: //www.facebook.com/dialog/oauth on it? Client_id = OTHER_APP_ID & redirect_uri = http://www.facebook.com/connect/login_success.html&response_type=token. An application can try downloading this URL using the most popular facebook apps apps. The application will receive a "Successful" message if the user has previously enabled OTHER_APP, since the login dialog and permissions will not be displayed. This will give EVE access_token access to all resources of the resource owner that the resource owner provided OTHER_APP, not EVE.
So is this a security hole? Did I miss something in the following?
(UPDATE)
Obviously, in the case of the desktop application, security problems do not matter, since the application already has a username and facebook session, as well as a username and password, it can do anything with a user account.
(UPDATE) For JavaScript applications running in a web browser, redirect_uri actually works! (See Reply and comments from hnrt).
CURRENT QUESTION: The only remaining secret is how client authentication works on iPhone and Android applications? Is security integrity similar to one when using a desktop application? Is there any difference in jailbreak ions or rooted androids?
Hooray!