The goal of a refresh_token is to request a new access_token when the previous access_token is (nearly) expired
However, it seems like you also rotate the refresh_token ánd invalidate the earlier refresh_token. (“A new refresh token will be issued in the response.”)
This is both unneeded (that’s why you have 2 tokens in OAuth instead of just 1 access_token) and very uncommon (eg. Google, Facebook, Twitter, … all have long-living refresh_tokens for good reason)
This causes Marketplace integrations to be very brittle – you only need 1 error (eg. a 500 error in your API, an error in token handling code, …) to ‘break the token chain’ and effectively require the end-user to go the approval flow again.
Can you explain the rationale behind this, or do I misinterpret something?
We started reissuing the refresh tokens, but we’re keeping an eye on the response from users (like you), and there’s a chance we might change this to a single everlasting refresh_token
Yesterday at 04/09/2018 at ~ 14:21 to 14:41 UTC, there was an issue with your service for 20 min. during which all token refreshes failed. Retries as soon as the service was back up were also failing, probably because the token was invalid by then or the earlier API calls failed after the refresh stage.
This means a large subset of our clients is now again disconnected, for the 4th time in 2 weeks. Please advise us on next steps how to deal with this mess…
For anyone who’s reading, I’m happy to say our dev team has been working on this and refresh tokens are now persistent. This should make things easier for many…