Child Item

Access token generated with refresh token got permissions revoked

As per the dropbox offline flow, I've set up a flow where I've generated a refresh token after the owner of the dropbox (me)
- Generated an access code using this URL
https://www.dropbox.com/oauth2/authorize?client_id<YOUR_APP_KEY>&response_type=code&token_access_type=offline
- Used the access code to generate a token using this request
curl https://api.dropbox.com/oauth2/token -d code=<ACCESS_CODE> -d grant_type=authorization_code -u <APP_KEY>:<APP_SECRET>

I was succesfully generating an access token with the refresh token that I got and my files were being uploaded.
After a month I come back and I get errors that my token no longer has permissions to do so.
This should not be the case since I did not set an expiration date on the refresh token or revoked any permissions.

Because this flow starts with an owner interaction, it cannot be restarted with an app in production as many uploads will be lost.
A new refresh token was generated and it all works now, but again I don't want this to happen in production.

How do I solve the issue?

Find more posts tagged with

Developers

Comments

Здравко

Hi @andrejpet,

I suspect, you're missing some details of how refresh token is used. Take a look on the discussion here for a detail ed example. Just don't forget the refresh itself; owning the refresh token is NOT enough!

Good luck.

andrejpet

@Здравко
I just read the info in the link you sent me and from what I've understood it's exactly the same as my explanation.
I am using a refresh token to generate an access token.
Then the access token is used for auth.

This happens on each request to dropbox.
1. Generate access token with refresh token
2. Perform API call with with access token

The problem I had is that after a given period of time the access token that was generated by a refresh token had no permissions.
This is my issue.

Здравко

Hm...🤔 Ok. @andrejpet, let me ask, after initial receiving of access token with grant type access code, how often you need to and receive access token with grant type refresh token? In other words, how often you do a call something like:

curl https://api.dropbox.com/oauth2/token -d grant_type=refresh_token -d refresh_token=oDfT54975DfGh12345KlMnOpQrSt01a -u <App key>:<App secret>

Hope the rhetorics gives direction. 😉

andrejpet

@Здравко

I need to do this on every file upload.
I do not control when the file is going to be uploaded and I'm not in a position where I can get an access token that lasts only 4 hours.
Hence the decision to go with a refresh token (that lasts forever) and use it to give me a new access token before each upload.
There were some online solutions following this path and claimed it worked.
The same happened on my end up until one request failed due to the access token generated by the refresh token had insufficient permissions.

The whole flow is a bit complicated so if you could point me into the right direction I would be really grateful.

My confusion lies in the part where I was getting valid access tokens with my refresh token for a month and then all of the sudden my access tokens have no permission.

Здравко

@andrejpet, unfortunately I cannot say much more than what's already said in the thread I linked to above. I think it's detailed enough. Even more it's the first time, I know about for such thing, you described:

@andrejpet wrote:
...
My confusion lies in the part where I was getting valid access tokens with my refresh token for a month and then all of the sudden my access tokens have no permission.

If you have valid refresh token and you're able to get valid access token at least once, you can always get other access token with the same validity again, so such a situation is impossible. The only way refresh token lost validity is revoking. Even more, in such a case you cannot receive access token with limited validity, you'll not be able receive any access token - you'll receive error on a try then (no receiving access token with no permission).

@andrejpet wrote:
...
I need to do this on every file upload.
...

It's not something mandatory. You can calculate when the token will expire on every refresh (the refresh moment + validity period) and on every regular API call (before the call actually) check if the current moment goes close to the expiration moment. If the moment is too close (let say less than a 2 or 5 minutes) perform new refresh and perform the ongoing regular API call after that and so on. This is the way; in such a way you will perform exactly so much refreshes as needed, neither more or less. 😉

@andrejpet wrote:
...
I do not control when the file is going to be uploaded and I'm not in a position where I can get an access token that lasts only 4 hours.
...

Ha...🙂 Really? And who is in such a position if not you? 😁

Add: You didn't mention what development environment (programing language) you're using. If you use such that can be in use together with some of the supported Dropbox SDK's, you don't need to do anything of that we discussed here. Everything is implemented there; you'll need only to initialize properly client object.

Greg-DB

@andrejpet I see Здравко already helpfully offered some guidance, but if you still need help with this, it may be useful if you can share the relevant code snippet and the error/output you're getting. For instance, clarify exactly what you mean when you say "all of the sudden my access tokens have no permission"; are you getting 'expired_access_token', 'invalid_access_token', or some other error?

andrejpet

@Greg-DB
Luckily I still have my old refresh token and I performed another request and this is what I got back.

Unable to write file at location: uploads/1.txt. Client error: `POST https://content.dropboxapi.com/2/files/upload` resulted in a `401 Unauthorized` response:\n
{"error_summary": "missing_scope/...", "error": {".tag": "missing_scope", "required_scope": "files.content.write"}}

Please keep in mind that I was not getting this 401 error before and I was successfully going throw the whole flow.

Hence my explanation that my refresh token generated an access token that does not have all the permissions.

Здравко

@andrejpet wrote:
...
Hence my explanation that my refresh token generated an access token that does not have all the permissions.

@andrejpet, Yes, of course, but this doesn't happen suddenly! Actually you never had such permission granted to the refresh token and following to the access token. You need to make sure you have the needed scope (i.e. files.content.write) and perform OAuth anew. Only changing scopes is NOT enough! Such a change is not retroactive. It'll affect tokens from following OAuths only.

Hope this helps.

Greg-DB

@andrejpet Thanks for following up. A 'missing_scope' error indicates that while the app itself may be permitted to use that scope, the particular access token you're using to make the API call does not have that scope granted. Also, be aware that just adding a scope to your app via the App Console does not retroactively grant that scope to existing access tokens or refresh tokens. That being the case, to make any API calls that require that scope, you'd need to to get a new access token/refresh token with that scope included. Refer to the OAuth Guide and authorization documentation for more information.

So, in this case that should mean that either:

The particular refresh token used to retrieve that access token was not originally authorized with the 'files.content.write' scope, or
The /oauth2/token call with 'grant_type=refresh_token' used to retrieve that access token set the 'scope' parameter to a value not containing the 'files.content.write' scope, meaning that the resulting access token would not have that scope.

To fix 1, you'd need to re-authorize the app with the OAuth app authorization flow again to get a new refresh token/access token with that scope.

If 1 does not apply though and that refresh token does already have that scope, to fix 2, you'd only need to make that /oauth2/token call with 'grant_type=refresh_token' again but include the needed scope in the 'scope' parameter, or omit the 'scope' parameter entirely.

For reference, I just tested this functionality out myself and it is working as expected for me. If something isn't working properly, please share the full steps/code to reproduce the issue so we can investigate.

andrejpet

Could be that during the dev process I accidentally created a refresh token without the app having valid permissions.
Can we keep this discussion alive just in case something pops up again?

I just want confirmation that the refresh token lives forever.

Thanks for your replies, in the end I re-started the whole process
1. Generated an access code
2. Requested a refresh token
3. Used the refresh token to get a new access token on each upload
4. Uploaded files.

Was pretty sure I got the whole flow right from the get go, this surprised me as I did not recall creating an app without permissions, but let's see if the token scope goes missing again.
I've saved all the creds so if anything pops up I'll contact you again.

Thank you for your help.

Greg-DB

Dropbox API refresh tokens do not expire automatically, but they can be revoked on demand by the app or user.

And yes, you can reply here again if/when needed.

Здравко

@andrejpet wrote:
Could be that during the dev process I accidentally created a refresh token without the app having valid permissions.
...

If you used that token, for sure.