cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Want to know what we learned at IBC? Check out our learnings on media, remote working and more right here.

Dropbox API Support & Feedback

Find help with the Dropbox API from other developers.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Exposing client_secret when only implicit grant is used

Exposing client_secret when only implicit grant is used

pcworld
Explorer | Level 3

I am the developer of an API v1 app that I'm in the process of migrating to API v2 and OAuth 2.
For security and privacy reasons, the users' auth tokens are never sent to any third party servers (i.e. only to Dropbox), and I want to keep it that way.

In order to migrate the users to API v2 as seamlessly as possible, I would like to use the /token/from_oauth1 API call, which however requires the client_secret (I don't understand why though).

I only use the implicit grant flow. Would there be any security implications if I exposed the client_secret in order to perform the from_oauth1 call client-side? As far as I can see, the client_secret only serves protecting the authorization code flow (apart from the from_oauth1 API call). As I'm not using it I don't see how an attacker could do any more harm if they are in possession of the client_secret.
Is this assessment correct and can I expose the client_secret without any issues?

 

On a side note, due to shortcomings in API v1 with OAuth 1, my app currently exposes the old API v1 "key" (there was no way avoiding that without using a third party server for authentication). Can the current client_secret be derived from this? If so, I don't need to worry any further since it would be compromised already anyway.

1 Reply 1

Greg-DB
Dropbox Staff

Hi,

 

 

"the /token/from_oauth1 API call, which however requires the client_secret (I don't understand why though)"

 

The /2/auth/token/from_oauth1 endpoint is an API v2 endpoint and isn't signed using the normal OAuth 1 protocol, but it does require all four token pieces (app key, app secret, access token key, access token secret) in order to maintain the same authentication requirements as an actual OAuth 1 call.

 


"I only use the implicit grant flow. Would there be any security implications if I exposed the client_secret in order to perform the from_oauth1 call client-side"

 

I can't offer general security advice, so if you have any security questions, you should contact a security professional. 

 

That said, you're correct that the app secret is used by the OAuth 2 "code" flow (and not the "token" a.k.a. "implicit" flow). With both the app key and secret, an attacker may be able to convince the user to give them an access token for their account and your app by using the "code" flow without a redirect URI.

 

The app secret is also used to sign webhook notifications.

 

 

"my app currently exposes the old API v1 "key" (there was no way avoiding that without using a third party server for authentication). Can the current client_secret be derived from this? "

 

No, the app secret cannot be derived from the app key. The app key is generally considered public, so it's ok to expose it.

 

Hope this helps! 

Need more support?
Who's talking

Top contributors to this post

  • User avatar
    Greg-DB Dropbox Staff
What do Dropbox user levels mean?