Your workflow is unique 👨💻 - tell us how you use Dropbox here.
Forum Discussion
OAuth2 public app key security
I'm just in the process of updating a few things and wanted to clarify how things are handled in terms of OAuth2 (and specifically, in this case, Android).
Basically it's my understanding that the app key must be included as both R.string.app_key and in AndroidManifest.xml in order for the implicit Auth behavior to work correctly. This is all pretty slick, but the obvious shortcoming is that the key is exposed publicly, not just to industrious APK decompilers, but in the URL of the authorization page itself.
Technically this means that anyone (i.e., any app) could easily find and use my app's key to generate an access token via the same authorization method, and therefore masquerade as my app while accessing a user's Dropbox, no?
The one point of security would be when someone taps Dropbox in NefariousApp and they get a webpage saying "MyApp would like to access your Dropbox" instead of "NefariousApp would like to access your Dropbox" — is that correct? In that case you're relying on either (a) the user to notice the discrepancy or (b) a nefarious app to not be trying to exactly mimic one's own app.
(For the record, I'm aware that this is not a Dropbox-specific issue. I'm just trying to clarify how things work in relation to the current v2 API.)
3 Replies
Replies have been turned off for this discussion
- Greg-DB
Dropbox Community Moderator
It sounds like you already have a pretty good handle on this, and (as you mentioned) since this is more about OAuth 2 itself, as opposed to Dropbox, there are likely plenty of good resources available online for more reading.
To add a few points and address your questions though, the app key does get exposed publicly, but the app key isn't considered a secret value, so this is fine and expected. The app secret, on the other hand, doesn't need to be exposed. If an attacker has your app key though, they can initiate an OAuth 2 app authorization flow, impersonating your app, but note that if they only have the key, they can only use the "token" a.k.a. "implicit" OAuth 2 flow, which requires a pre-registered redirect URI. Redirect URIs can only be set from your developer account via the App Console. You can find some more information in the documentation under /oauth2/authorize.
We also have an OAuth guide that may be helpful.
Finally, apps that don't need to use the implicit a.k.a token flow, e.g., purely server-side apps, can disable it via the App Console.
Thanks for following up. Okay, that's just the part I was looking into.
Is that true for an Android app? Currently my redirect URI is blank. So after I click to allow (in the Android browser) I get a confirmation and am brought back to my app, where Auth.getOAuth2Token() now returns a valid (presumably) access token.
- Greg-DB
Yes, but for the official Dropbox SDKs in particular, we handle some of the redirect URI configuration automatically to make it easier when getting started.
About Dropbox API Support and Feedback
Get help with the Dropbox API from fellow developers and experts.
