You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
short lived access token is invalid seconds after login
Hello everyone,
a client of mine wanted to test the app that I made for them for the first time.
- They were able to accept that my app is going to access their files ✔︎
- they were redirected to the web app I made for them ✔︎
- I can see the short lived access token in the url ✔︎
Yet, when they try to access a folder via the web-app they get an invalid access token error. For me, I have no problems using the same web-app whatsoever. Does anyone have any idea why this might happen? The only vague idea that I have is that maybe their office VPN is messing up something, but I can't imagine how.
Appreciate any ideas.
Thanks for the additional information. That's helpful. The extra portion you're seeing on the access token is a region suffix, which Dropbox will append in certain cases. The access token is still meant to be opaque, so the app should still just use the access token string as provided, including that suffix, if present.
However I see the issue is that the value isn't being decoded before use, so attempting to use the encoded "%3AEUR" version fails. If you use the decoded version ":EUR", the access token should still work.
How are you parsing the access token from the redirected URL? You should make sure to decode it as a URL parameter when doing so, like in the example included with our JavaScript SDK, which uses this method to parse and decode the parameters.
(Alternatively, the newer and now recommended method for client-side apps is to use the PKCE flow, such as shown in this example for our JavaScript SDK. In that flow, the access token isn't returned on the redirected URL itself anyway.)
- Greg-DB
Dropbox Staff
An access token shouldn't be immediately invalidated like that. It sounds like the access token string itself is somehow getting corrupted somewhere in the process.
For reference, it sounds like you're getting an 'invalid_access_token' error, indicating that the supplied access token isn't valid. This indicates that the access token hasn't just expired; if it was expired that would cause an 'expired_access_token' error.
Anyway, I'll be happy to help investigate, but I'd need some more information:
- the name and version number of the platform and SDK/library you are using, if any
- the steps to reproduce the issue, including relevant code snippet(s), but don't include any access or refresh token(s)
- the full text of any error or unexpected output
Yes indeed, it is an 'invalid_access_token' in the response.
I asked the client to send me the whole url that they are redirected to after login, since I never had an issue with this and can't test it. Turns out their access token is longer and it ends with an '%3AEUR', which looks like url_decoded ':EUR'. Two separate persons tried it. Both using macOS just like me, testing in Chrome and Safari like me. Only difference I see is they tried it in a different location from me.
Removing the extra suffix from the access token in the url solves the problem. I can also remove that part in code, but the question that remains is, why it was added at all.
- I use the Dropbox JavaScript API ("dropbox": "^10.4.3")
- The only line of code that is used from the API that comes before the faulty access token is:
- `const authUrl = await dbx.auth.getAuthenticationUrl(window.location.href)`
- the returned authentication URL should be correct though, since there is no invalid redirect_url error.
I asked the client to copy the generated authentication url anyway, just to be sure there is nothing going on there.
- Greg-DB
Thanks for the additional information. That's helpful. The extra portion you're seeing on the access token is a region suffix, which Dropbox will append in certain cases. The access token is still meant to be opaque, so the app should still just use the access token string as provided, including that suffix, if present.
However I see the issue is that the value isn't being decoded before use, so attempting to use the encoded "%3AEUR" version fails. If you use the decoded version ":EUR", the access token should still work.
How are you parsing the access token from the redirected URL? You should make sure to decode it as a URL parameter when doing so, like in the example included with our JavaScript SDK, which uses this method to parse and decode the parameters.
(Alternatively, the newer and now recommended method for client-side apps is to use the PKCE flow, such as shown in this example for our JavaScript SDK. In that flow, the access token isn't returned on the redirected URL itself anyway.)
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
