API v2 for iOS, Mac OS X, Windows, Linux, Android - need strategic advice

Hi Gregory,

thanks for response. I'm already looking at the docs and it looks like I will be going the c++ way with http post + json.

I understand that authorization flow should be handled by Dropbox web site. I'm just thinking that when it comes to security there isn't much difference between that approach and for example sending http post request with user name and password as parameters in json, and then getting response with access token. It would provide seamless integration, more like iCloud. It is true, that user would have to trust the app to let it handle username and password, user would have to trust that the app doesn't store this username and password, because this provides access to entire Dropbox account, not just app folder. The app would have to save only access token. But handling this with in-app browser isn't a better approach. Malicious app could provide in-app browser and show exact same interface as Dropbox web site, so user wouldn't notice any difference.

When it comes to security I would actually prefer a different solution:

1. MyApp would send http request with app id, app secret string, user id and a random token generated by the app (and perhaps name of the device, so the user could better identify that it is his/her request).

2. User would receive notification on the device (if enabled) - like iOS or Mac OS X notifications.

3. User would start Dropbox client (on iOS, Android or desktop client) and approve the app through Dropbox client, because only this app can be trusted when entering Dropbox password.

4. User would switch back to MyApp and it would simply send another http request with app id, app secret string and random token generated before. The response would contain access token. The random token would assure that only the client, who sent the request, would receive access token.

Advantages:

1. User doesn't have to trust the app with Dropbox password

2. Every user would more likely install Dropbox client (good for Dropbox). Today you don't really need to install Dropbox client, which means user is less involved with the Dropbox ecosystem.

3. No custom URLs need to be defined - it may be tricky on some platforms, also launching app through URL scheme may be a security weakness, if the input is not handled properly.

4. Potentially it could serve to detect denial of service attacks - someone generating too many requests for app authorization.

it's just a thought. I can implement whatever interface is currently available. The only problem is that doc says API v2 interfaces are "BETA - Not ready for production". I was hoping to have something I could release in 2 weeks or so.