Attempt to relink Dropbox? keeps recurring

---

Bob S.15 wrote:

...  I did change the flow to the new calls, but do I need to do something specifically to store this new short-lived token?  ...

---

You don't need to do anything special to store "this new short-lived token" (probably you mean the access token). You can continue using the same way or use any other. The main question is what are you doing to store and reuse the refresh token!!! Are you doing something? 🧐

Bob S.15 Thanks for following up with the additional information. As you found, 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. (We did send notice of this migration by email, but it sounds like those emails may not have made it to you.)

The 'expired_access_token' error indicates that the call failed because it was made using an expired short-lived access token. 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.)

The official Dropbox Objective-C SDK will actually handle this for you automatically as long as you set up the authorization flow as documented (that is, using authorizeFromControllerV2 and not authorizeFromController). That is, it will request and store the refresh token for you automatically, in addition to the access token. You don't need to do anything differently to handle those. You should just continue using the supplied authorizedClient and it will handle the refresh process for you.

Checking if authorizedClient is nil is still a valid way to see if you have a client, but that doesn't tell you if the stored token is still valid on the server (just like with previous long-lived access tokens which may have been revoked by the user remotely).  If you're getting 'expired_access_token' from an existing authorizedClient, that's likely because it was retrieved using authorizeFromController instead of authorizeFromControllerV2. You would need to unlink and relink with authorizeFromControllerV2 to get a client with a stored refresh token to have that handled automatically.

(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 released it gradually, so you may not have seen your app(s) affected until more recently. 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.)

And regarding the "An error occurred authorizing your app" error, have you migrated your app registration(s) to scopes yet? You can do so via the "Permissions" tab on the app pages on the App Console. You'll need to do so before you can use the new authorizeFromControllerV2 method. (Apologies for the generic error message! I'll ask the team to improve that.)