Child Item

Unable to get long lived access tokens.

Hello there!

I'm trying to get an access token that doesn't expire. A long-lived access token. For now, when I generated an access token from the App Console, the session will expire after x hours and won't give me a refresh token either.

I've checked the authentication documentation:

https://developers.dropbox.com/oauth-guide#implementing-oauth

But I can't find the Access Token Expiration like the documentation shows:

dropbox generate.png

Mine is displayed like this:

Screen Shot 2022-03-22 at 11.08.10 AM.png

As you can see, the option for the Expiration is missing.

So I kept looking and came across a similar question on the forums and I followed every step:

https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/Tokens-only-valid-for-4-hours-from-app-console/m-p/425358/highlight/true#M22718

Still can't get a long-lived access token.

Here's a test code:

access_token = "sl-ABC" # I want a long lived one.
app_key = "xyz"
dbxTeam: dropbox = dropbox.DropboxTeam(oauth2_access_token=access_token, app_key=app_key)
print('Dbx Team is: ', dbxTeam.as_user('dbmid:MY_USER_ID').users_get_current_account())

output:

{
'_oauth2_access_token':'sl....',
'_oauth2_refresh_token': None,
'_oauth2_access_token_expiration': None,
'_app_key': 'xyz',
'_app_secret': None,
'_scope': None,
'_max_retries_on_error': 4,
'_max_retries_on_rate_limit': None,

'_session': <requests.sessions.Session object at 0x1083b1730>,
'_headers': None,
'_raw_user_agent': None,
'_user_agent': 'OfficialDropboxPythonSDKv2/11.28.0',
'_logger': <Logger dropbox (WARNING)>,
'_host_map': {'api': 'api.dropboxapi.com',
'content': 'content.dropboxapi.com',
'notify': 'notify.dropboxapi.com'},
'_timeout': 100}

Any ideas on how to get a token that won't expire?

Find more posts tagged with

API

Abuse

Accepted answers

Здравко

Hi @OperationsDreaming,

Take a look on https://www.dropboxforum.com/t5/Discuss-Dropbox-Developer-API/Need-Permanant-Access-token-for-drop-box/td-p/583956 😉

In short - there is no more long lived access token and you should add refresh token in your code.

Hope this helps.

All comments

Здравко

Hi @OperationsDreaming,

Take a look on https://www.dropboxforum.com/t5/Discuss-Dropbox-Developer-API/Need-Permanant-Access-token-for-drop-box/td-p/583956 😉

In short - there is no more long lived access token and you should add refresh token in your code.

Hope this helps.

Greg-DB

@OperationsDreaming Здравко is correct. You'll need to implement support for refresh tokens. You can find example code for for the Python SDK here:

https://github.com/dropbox/dropbox-sdk-python/blob/main/example/oauth/commandline-oauth-scopes.py
https://github.com/dropbox/dropbox-sdk-python/blob/main/example/oauth/commandline-oauth-pkce.py

OperationsDreaming

@10

This works!

marksmithhfx

I have been using the long lived access token you can request when you setup your app, and have that embedded in my app. I use it to send a "synchronizing" file to DB whenever I make changes. I don't need to re-authenticate. My question is, if I know allow users to do the same thing, they will need to authenticate and I will get a short lived AT and a refresh AT. How much additional latency will they experience converting the AT from refresh to short lived? Currently the total latency to connect to DB and upload a file from my app is < 1/2 second, or barely noticeable. Will all of the "re-allocation" steps add significantly to this.

Thank you.

Здравко

Hi @marksmithhfx,

Your question is very generic, so it's difficult to receive exact answer. Additional time consumption is on refresh only. Since data size transferred is relatively negligible, establishing secure connection gets primary weight. In other words additional time depends on your connection latency more than the connection speed.

Other point you should consider, on evaluation, is usage time profile - i.e. how often, relatively, refresh will take on. Let's recall additional time will be added on refresh only, so if your usage profile predispose many calls in a 4 hours time frame, weight of the refresh will be negligible. If your calls bring up on intervals bigger than 4 hours then the relative weight might be bigger (on every calls burst - one refresh). Once the refresh take place, no difference can be expected for rest of calls - they are the same (no additional delay per call).

The best way to figure out exact answer in your particular conditions is... the check. 😉 Most probably it will be negligible.

Good luck.

marksmithhfx

Thanks. Great answer, and very reassuring. I will give it a go.

marksmithhfx

Well, as indicated in my previous response I have been "giving this a go" but with only partial success.

When I send my app key, app secret, scopes, port and “offline” to https://www.dropbox.com/oauth2/authorize

I get back the following:

Array

.. [account_id] => dbid:AAB27TU-12HrF0rn….

.. [refresh_token] => 29hxFtf-fnoAAAAAAAAAAQe….

.. [expires_in] => 14400

.. [uid] => 16196036

.. [scope] => account_info.read files.content.read files.content.write files.metadata….

.. [access_token] => sl.BFo00immyYa18QPnbABlmng….

.. [token_type] => bearer

Which is all well and good because what I want is a refresh token that I can use to request a sl. access token when the current one expires. This should also demonstrate that I know how to send an app key, secret, port and token_access_type to the URL provided.

However, when I send my grant type, refresh_token, app key and secret to https://api.dropbox.com/oauth2/token like it suggests in the guidance below (from the Developers guidelines) I always get an Error 404 page not found. I’ve also tried sending to https://api.dropboxapi.com/oauth2/token but get the same result. What am I doing wrong?

curl https://api.dropbox.com/oauth2/token \
    -d grant_type=refresh_token \
    -d refresh_token=<REFRESH_TOKEN> \
    -u <APP_KEY>:<APP_SECRET>

BTW, both end points (api.dropbox.com and api.dropboxapi.com) are given in the docs. I tried them both. Both were 404.

Thanks

Greg-DB

@marksmithhfx Is that the exact code you're running? It looks correct, and it does work for me when I plug in my values. There may be something about how your client is formatting the request causing it to fail. Perhaps you can share the actual request/response you're getting (just redacting the sensitive values) so I can take a look.

marksmithhfx

"Is that the exact code you're running?"

No, not exactly. I am using an OAuth2 package in the application development environment (it's like a fancy Visual BASIC) I am using. To get the refresh_token I was using this code (with redactions):

constant kAuthURL = "https://www.dropbox.com/oauth2/authorize"

constant kTokenURL = "https://api.dropboxapi.com/oauth2/token"

constant kClientID = "redacted" -- client here means this application, not this user

constant kClientSecret = "redacted" -- secret here is for this application, not this user

constant kScopes = ""

constant kPort = "54303"

since there is no parameter for token_access_type that is handled with:

put "offline" into tParams["token_access_type"]

then the call to OAuth2 itself...

OAuth2 kAuthURL, kTokenURL, kClientID, kClientSecret, kScopes, kPort, tParams

which successfully returned the array (actually JSON dictionary converted to array) I posted earlier.

This is the extent of the API I have, so I was trying to model the next step by writing:

put "refresh_token" into tParams["grant_type"]

put RefreshToken into tParams["refresh_token"] -- a var that contains the refresh token returned in the first step

-- I tested that both of these array values were properly formatted

and then calling:

OAuth2 kTokenURL, kClientID, kClientSecret, tParams

But all I get is a 404 Page not found error. I was hoping to get something more useful back (maybe you could think of a way I can do that?) so I could start to debug this, but all I get is the 404.

PS I did notice in the documentation that "authorization" is listed as a GET method and "token" as a POST method, but since I am not conversant in HTML that didn't mean anything to me. However, that might be the root cause of the problem. The application API might be formatting both as GET statements instead of the required POST one. (I should probably lookup GET and POST). Thanks

Greg-DB

@marksmithhfx Thanks for following up with the additional information. The "GET" and "POST" are referring to the HTTP "method" for the HTTP request. Every HTTP request uses one of a number of methods, for various different use cases, with GET and POST being two of the most commonly used ones.

The Dropbox /oauth2/token endpoint in particular does require the use of the POST method. Using GET could cause the issue you're seeing.

Unfortunately I can't offer support for the "OAuth2" package you're using itself, as that's not made by Dropbox. You may need to refer to its documentation for information on configuring and debugging it. For instance, there may be a way to enable more verbose debugging output. Likewise, check how you might configure the appropriate HTTP method to use to make sure it uses POST for the request to /oauth2/token.

marksmithhfx

Thanks Greg, you have confirmed what I was suspecting. In order to covert the refresh token to a new sl.access token a new kind of method needs to be used (POST) which does not appear to be supported in the current version of the OAuth2 package I am using. I will prepare something to pass along to LiveCode so they can update their OAuth2 (if they want). Using sl.access tokens that require frequent re-authorization is not ideal, but given no other alternative, I'll hobble along for awhile and see what develops down the road.

Cheers and thanks.

Mark

marksmithhfx

Thanks Greg,

You know, I was thinking, what a shame Dropbox did not implement the refresh exchange process using the GET method. I am sure, since I have the ability to add additional parameters, that I could define a grant_type = "refresh_token" and a refresh_token parameter that contains the refresh token, and send that with the existing ClientKey and ClientSecret and get the result back on the same URI and all would be great.

Do you know why Dropbox chose POST over GET in this case?

PS you mentioned to check their documentation, but all it includes is the following:

Summary

Present an authorization dialog for any web service that supports OAuth2 Authorization Code Flow

pAuthURL - The URL to present for the authorization page. This can be obtained from the API documentation of the service being authorized.

pTokenURL - The URL to obtain the authorization token from once an authorization code is sent to the redirect uri. This can be obtained from the API documentation of the service being authorized.

pClientID - The application client ID obtained when setting up your application with the web service.

pClientSecret - The application client secret obtained when setting up your application with the web service.

pScopes - A comma delimited list of authorization scopes. Valid scopes will be found in the API documentation of the service being authorized. If empty the scope parameter will be omitted.

pPort - The port to use for the redirect uri. It is recommended to use the range 49152-65535.

pParams - An array of additional key -> value pairs of extra parameters to be sent to the authorization url. Some services implement additional options that require extra parameters.

Examples

constant kAuthURL = "https://slack.com/oauth/authorize"

constant kTokenURL = "https://slack.com/api/oauth.access"

constant kClientID = "XXXXXXXXX.XXXXXXXX"

constant kClientSecret = "XXXXXXXXXXXXXXXXXXXXX"

constant kScopes = "incoming-webhook"

OAuth2 kAuthURL, kTokenURL, kClientID, kClientSecret, kScopes, 54303

--- end

By tagging on an extra parameter (token_access_type = "offline") I was able to obtain a refresh token, but can't do anything with it. Unfortunately no mention of GET or POST.

Mark

Greg-DB

@marksmithhfx It looks like the use of POST for these requests is required in the OAuth 2 specification:

The client MUST use the HTTP "POST" method when making access token requests.

I'll send this along as a feature request to support GET as well, but I can't promise if or when that might be implemented (especially as it would be contrary to the specification).

marksmithhfx

Thanks Greg, but I would nix that. After looking at your post and the documentation again I realized that the LiveCode commands:

put "offline" into tParams["token_access_type"]

OAuth2 kAuthURL, kTokenURL, kClientID, kClientSecret, kScopes, kPort, tParams

must be doing both a GET and a POST (the GET for authorization, and the POST for the access token) because, per the documentation:

/oauth2/token

METHOD POST

This endpoint returns a JSON-encoded dictionary including fields below:

access_token String The access token to be used to call the Dropbox API.

expires_in String The length of time in seconds that the access token will be valid for.

token_type String Will always be bearer.

scope String The permission set applied to the token.

account_id String An API v2 account ID if this OAuth2 flow is user-linked.

team_id String An API v2 team ID if this OAuth 2 flow is team-linked.

refresh_token String If the token_access_type was set to offline when calling /oauth2/authorize, then response will include a refresh token. This refresh token is long-lived and won't expire automatically. It can be stored and re-used multiple times.

Which is exactly what I am getting from the OAuth2 command above. So it is my misunderstanding when I said it was not using POST. It's using both. Only problem is, it was written before the age of refresh_tokens so it doesn't know what to do with them.

I'll just leave it to the experts to sort out and hope it doesn't take too long.

Thanks again,

Mark

marksmithhfx

Hi Greg, the response came, and quicker than I was expecting. Also very DIFFERENT than I expected. We had previously been discussing the recommendation in the DB documentation:

curl https://api.dropbox.com/oauth2/token \
    -d grant_type=refresh_token \
    -d refresh_token=<REFRESH_TOKEN> \
    -u <APP_KEY>:<APP_SECRET>

But the result I got back from Livecode, which works perfectly, looks like this:

-- given a refresh token in var tRefreshToken...

set the httpHeaders to "Content-type: application/x-www-form-urlencoded" & \

return & "Authorization: Basic " & base64encode(kClientID & ":" & kClientSecret)

put "grant_type=refresh_token" & "&" & "refresh_token=" & tRefreshToken into tPost

put "https://api.dropbox.com/oauth2/token" into tUrl

post tPost to url tUrl

put JSONToArray(it) into tAuth

put tAuth[access_token] into tAccessToken

Naw, I would have never figured that out. But it works. And I am grateful.

Thanks for your previous attempts at resolving this.

Mark