We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
Obtaining short lived API Access tokens
Hello, I'm struggling with the process of obtaining/refreshing short lived tokens. I have a remote camera that will occasionally upload a picture using HTTP over the cellular network. The API works but of course the token generated in the App console times out so ... I dived into the documentation. Many many hours later I'm possibly more confused than ever. I'm working mainly from: "developers/documentation/http/documentation"
I believe what I need to do is this:
Example: Auth URL for code flow with offline token access type
"https://www.dropbox.com/oauth2/authorize?client_id=<APP_KEY>&token_access_type=offline&response_type=code"
which I have done and eventually got an "Access Code" which I think will be used by the camera to request a short lived token.
I'm guessing that every time the camera has a picture to upload, it will first have to send a request for a new token using the Access code? Am I right in thinking this access code will "live forever" unless I revoke/cancel/destroy it?
I tried to request a token with the method "Example: access token request in code flow" but had no success.
Am I on the right track or hopelessly in the weeds?
I hope I don't need to worry about Redirect URIs
The token request examples all use curl which introduces another level and failure point for me and my camera app.
I tried converting it to HTTP and an error there could by my problem.
For context, Dropbox is in the process of switching to only issuing short-lived access tokens (and optional refresh tokens) instead of long-lived access tokens. You can find more information on this migration here.
Apps can still get long-term access by requesting "offline" access though, in which case the app receives a "refresh token" that can be used to retrieve new short-lived access tokens as needed, without further manual user intervention. (Refresh tokens don't expire, but can be revoked on demand.) You can find more information in the OAuth Guide and authorization documentation.To clarify what you have so far though, the code returned from /oauth2/authorize when using 'response_type=code' like this is an "authorization code", which is different than an "access token" or "refresh token". Authorization codes are temporary, single-use codes that the app should use once to retrieve the authorization result (which would be an access token and optionally a refresh token).
And yes, using a redirect URI is optional with this 'response_type=code' flow. When the redirect URI is omitted, the authorization code is just presented on the Dropbox web page so it can be copied/pasted back into the app manually.
So, to summarize, the flow would look like this:
- the app builds the /oauth2/authorize URL ("Example: Auth URL for code flow with offline token access type")
- the user visits the /oauth2/authorize URL in their browser and authorizes the app
- the user copies the authorization code back into the app
- the app sends the authorization code to /oauth2/token and receives back a short-lived access token and refresh token ("Example: access token request in code flow")
- the app makes calls using the short-lived access token until it expires
- the app sends the refresh token to /oauth2/token and receives back another short-lived access token, whenever and as many times as necessary in the future ("Example: refresh token request")
- Greg-DB
Dropbox Staff
For context, Dropbox is in the process of switching to only issuing short-lived access tokens (and optional refresh tokens) instead of long-lived access tokens. You can find more information on this migration here.
Apps can still get long-term access by requesting "offline" access though, in which case the app receives a "refresh token" that can be used to retrieve new short-lived access tokens as needed, without further manual user intervention. (Refresh tokens don't expire, but can be revoked on demand.) You can find more information in the OAuth Guide and authorization documentation.To clarify what you have so far though, the code returned from /oauth2/authorize when using 'response_type=code' like this is an "authorization code", which is different than an "access token" or "refresh token". Authorization codes are temporary, single-use codes that the app should use once to retrieve the authorization result (which would be an access token and optionally a refresh token).
And yes, using a redirect URI is optional with this 'response_type=code' flow. When the redirect URI is omitted, the authorization code is just presented on the Dropbox web page so it can be copied/pasted back into the app manually.
So, to summarize, the flow would look like this:
- the app builds the /oauth2/authorize URL ("Example: Auth URL for code flow with offline token access type")
- the user visits the /oauth2/authorize URL in their browser and authorizes the app
- the user copies the authorization code back into the app
- the app sends the authorization code to /oauth2/token and receives back a short-lived access token and refresh token ("Example: access token request in code flow")
- the app makes calls using the short-lived access token until it expires
- the app sends the refresh token to /oauth2/token and receives back another short-lived access token, whenever and as many times as necessary in the future ("Example: refresh token request")
Thanks for the quick answer! The flow is a lot clearer to me now. Is it possible to change the "oauth2/authorize_submit" page to refer to the code it returns as an Authorization code instead of an Access code? It is a small thing but I'm probably not the only one wondering where an "Access code" should be used and where/how I could obtain an "Authorization code".
- Greg-DB
Thanks for the note! I'll ask the team to fix up that text.
About Discuss Dropbox Developer & API
Make connections with other developers
