This feel sus, as the kids say, but is it? I control the authorized origins and redirect URIs, so it’s not clear to me how someone could use those strings to impersonate my app.
Yes, that’s why it’s OK to do.
Also, even when distributing your app as a native iOS or Android app, someone can easily get the credentials from parsing requests from an HTTPS proxy if they wanted to. So it’s not really a secret that can be safeguarded entirely to begin with.
[updated]
Hi @dustin,
The app key is fine, as long as you don’t put in the app secret!
I had a look at the Dropbox docs and referring to a 2020 blogpost it says:
Prior to the introduction of PKCE, the implicit grant flow was the recommended solution to applications which cannot secure a client_secret.
Dropbox continues to support this legacy flow for compatibility, but recommends PKCE for new apps. You should disable the implicit grant option in App Console if you are not using it.
I seem to remember that when dropbox.js first came out in 2012 it was using the app secret in the client-side which was an anti-pattern, but I think we’ve come a long way from that since.