Hidding app_key and app_secret inside a possible desktop app

You're right that the app key is public information, and someone can use that together with the implicit flow to impersonate your app. If you're building a pure server-side app, you can disable the implicit flow to prevent this, but otherwise, this is simply how OAuth works. (This security model is not specific to Dropbox.)

To use the implicit flow with Python, you would have to do the OAuth flow yourself, but once you have an access token, you can use the SDK as-is. You're right that to take someone through OAuth in a desktop app, you would typically embed an in-app browser, run a local webserver, or register a custom URI scheme on the client. Of those options, we generally recommend embedding a browser. As an alternative, you could use the native browser and just redirect to a page that displays the token and asks the user to copy/paste it into the app. This is obviously not as smooth of a user experience, but you may find the redirect URI https://www.dropbox.com/1/oauth2/display_token helpful for this purpose.

Moved to the API forum.

This is an issue inherent to using OAuth 1 with a client-side app. If you're using OAuth 1, this is unavoidable. You can try to obfuscate the keys to make it difficult, but you can't make it impossible to extract them. If they are extracted, this doesn't itself enable access to user data though, it would just let someone else impersonate your app.

With OAuth 2, you can use the "token" a.k.a. "implicit" flow, which doesn't require the use of the secret anyway:

https://www.dropbox.com/developers/core/docs#oa2-authorize

Hi,

I have the same problem now but I have another question to your proposed fix. The "implicit" flow of OAuth 2.0 still requires the "app_key", which has to be stored in the application itself, thus enabling others to impersonate my app with the implicit flow. I don't understand the exact role of the app secret.

Also: The current Python SDK doesn't support the implicit flow by itself, so I am forced to use the RESTClient which is used internally by the SDK, right?

Edit: After some testing I found that the implicit flow requires a redirect_uri. The problem with that is, I can't intercept the redirect to the URI without a local webserver or an in-app browser. Is there any way around this?

Just for clarification: I am talking about a desktop application, not a client browser application using JavaScript or anything.

I stumbled upon this topic and found the display_token URL (which doesn't seem to be mentioned anywhere in the docs, BTW), but I can't get it to work. I think I have set up everything correctly. I can get it to redirect to https://www.dropbox.com/1/oauth2/display_token?code=<code_here>, but the code is only visible in the URL bar, and the "copy this token" box does not get populated. This is not a smooth experience, but it seems to be almost-there. Is it an issue with the page itself or could it be my configuration?

Hi Antriksh, the display_token page was designed for the "token" flow, not the "code" flow. You can find information on the two different flows in the /authorize documentation here:

https://www.dropbox.com/developers/documentation/http/documentation#oauth2-authorize

If you want to use the code flow and have the code displayed to the user, you can just omit the redirect_uri on /authorize.