Corrupt OAuth2 Tokens

[Steven_R]

We did an integration with Dropbox about 2 years ago and it has been working quite well. However we have started having some issues where we get an error 422 no_permission when we make api calls for some clients despite having just gotten the token.

It seems that the OAuth2 Token we get is sometimes unusable. If we get a 422 error then we will always get a 422 error for that token. If the same user re-authorises again and gets a new token then the problem will often go away. That is until the next time they need a new token at which point it could happen again.

Note: Previously we were getting long lived tokens and they are still working fine, but recently we have been getting short-lived tokens and they seem to be the ones having the issue. Our integration has access to the whole of Dropbox, not just the App folder.

Is there a known issue where some tokens are invalid?

[Здравко]

---

@Steven_R wrote:

...

Is there a known issue where some tokens are invalid?

---

No, just generation of long lived tokens is dropped already. Existing could still be used. You should care to include in your authentication flow the refresh token, generated when you select 'offline' (like it was for long lived token). Take a look on the corresponding examples (matching your SDK) for more info about implementation.

[Greg-DB]

@Steven_R As Здравко mentioned, 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. You can find more information in the OAuth Guide and authorization documentation.

For reference, while the creation of new long-lived access tokens is now deprecated, we don't currently have a plan to disable existing long-lived access tokens. (If that changes, we will of course announce that ahead of time.) That being the case, you can continue using existing long-lived access token(s) without interruption, if you have any. Also, note though that after the change you won't be able to create new long-lived access tokens.

While the change began on September 30th 2021, we're releasing it gradually, so you may not have seen your app(s) affected until now. Once it applies to your app, it would apply regardless of the "Access token expiration" setting for your app, and that setting may no longer be available for your app.

However, that would not affect what an access token can do; it only affects how long an access token is valid for. A 422 error code in particular can indicate an issue with the "Dropbox-API-Path-Root" value the app is setting for the user. Please refer to the documentation here for more information on that.

[Steven_R]

Thanks for the reply, but I don't think that is the issue.

We are very familiar with refresh/long/short lived tokens as we integrate with a number of other systems such as SharePoint/OneDrive/Google Drive and our system handles each of these situations without issue.

The dropbox clients who currently have long lived tokens are not having this issue at all.

The only clients who are experiencing the 422 error are those with short lived Dropbox tokens. The root id is stored for a user and it used every time for that user, which has been the case for the last 2 years without issue prior to short lived tokens.

a) We have a situation where a short lived token is issued, the rootid is provided and it works fine until it expires.

b) We get another token and use the same rootid but we will get the 422 error. The 422 error will happen every time until we get another token.

c) We then get another token and try again at which it either works or it doesn't as per a) or b).

The point being is that some shortlived tokens produce this error even when the call has the correct rootid and other tokens don't, even though the call (except for the token) is identical. 

[Greg-DB]

@Steven_R We'll be happy to look into this specifically for you. Please open an API ticket here, with the following information:

• an affected account ID
• a sample HTTP request/response for a failure for that account, including both headers and body for both request and response, but redacting the access token itself
• a few additional 'X-Dropbox-Request-Id' response header values for these failures