1

I'm only a student, so forgive me if my understanding is poor or my ideas poorly expressed.

I want to create a purely client-side browser application that works with the user's Dropbox account. They would go to the page, click 'Connect My Dropbox', grant permission, get the access token back, and store it in local storage. Then, the application would make requests directly to the Dropbox API to fetch the contents of a given folder and do whatever -- display a Markdown editor for their .md files, or create a gallery for their images, or something.

My understanding of the OAuth flow is that:

  • When the user clicks 'Connect My Dropbox', they go to eg dropbox.com/auth?clientID=foo
  • If they click 'allow', Dropbox redirects them to whatever I specified as my callback URL, with an auth code in the query string
  • When that triggers a request from the user to my callback-URL endpoint, I grab the auth code, and send a request to dropbox.com/turn_auth_code_to_token?client_id=foo&client_secret=bar&auth_code=baz
  • Dropbox sends me back a token I can use to make API requests.

If my understanding is right, then it's not possible for me to make an application that uses OAuth and has no server-side component, because turning the auth code into an access token requires supplying the client secret. If I put the client secret in the front end code, anyone could just pull it out and do shady stuff disguised as me.

Is that right?

If so: am I required to implement at minimum a server that listens to requests for my callback URI and returns access tokens? And from there, can users store their access tokens locally and use them?

2

If my understanding is right, then it's not possible for me to make an application that uses OAuth and has no server-side component, because turning the auth code into an access token requires supplying the client secret. If I put the client secret in the front end code, anyone could just pull it out and do shady stuff disguised as me.

Is that right?

No, you are not right. OAuth specification describes different flows - Implicit Flow among them. In this flow you do not use client secret as you cannot guarantee storing it safely.

Implicit Grant (OAuth 2.0 spec https://tools.ietf.org/html/rfc6749)

The implicit grant type is used to obtain access tokens (it does not support the issuance of refresh tokens) and is optimized for public clients known to operate a particular redirection URI. These clients are typically implemented in a browser using a scripting language such as JavaScript.

Of course this solution includes some security trade-offs which are described well in the specification. As I really recommend reading OAuth specification here is a link https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2 with compressed info about OAuth flows.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.