Miro OAuth refresh tokens are single use: rotating access kills the old refresh token too

TL;DR

Gotcha to avoid: rotating the access token without also persisting the new refresh token, then failing every subsequent refresh. With expiring tokens the access token lasts 1 hour and the refresh token lasts 60 days. Every refresh returns a brand new pair, and the old access token and refresh token stop working immediately.

When to use

You are seeing this: With expiring tokens the access token lasts 1 hour and the refresh token lasts 60 days. Use this skill when you run into "Miro OAuth refresh tokens are single use: rotating access kills the old refresh token too".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Miro OAuth: refresh tokens die the moment you use them Picked expiring tokens when you created your Miro app? Then your access token lives for 1 hour and your refresh token for 60 days. Here is the part that bites: the moment you use the refresh token to get a new access token, Miro hands back a fresh pair and kills both old tokens. If your code only saves the new access token and keeps the old refresh token around, the next refresh fails and your users have to reauthorize. Concrete failure sequence: 1. You exchange the authorization code and get access token A + refresh token R1. 2. An hour later you refresh with R1. You get access token B + refresh token R2. 3. Your code stores access token B but forgets to overwrite R1. 4. Next hour you try to refresh with R1. Miro rejects it: R1 died the instant R2 was issued. The fix is boring but mandatory: whenever the refresh response comes back, overwrite both stored tokens, not just the access token. Second gotcha: you cannot flip an app between expiring and non-expiring tokens after creation. If you created the app with the wrong setting, you create a new app.

Context: Miro OAuth expiring tokens: 1 hour access, 60 day refresh, old pair invalidated on each refresh Miro lets you pick expiring or non-expiring tokens when you create an app, and you cannot change that setting later. With expiring tokens the access token lasts 1 hour and the refresh token lasts 60 days. Every refresh returns a brand new pair, and the old access token and refresh token stop working immediately. Gotcha to avoid: rotating the access token without also persisting the new refresh token, then failing every subsequent refresh.

Source: Miro OAuth expiring tokens: 1 hour access, 60 day refresh, old pair invalidated on each refresh Miro lets you pick expiring or non-expiring tokens when you create an app, and you cannot change that setting later. With expiring tokens the access token lasts 1 hour and the refresh token lasts 60 days. Every refresh returns a brand new pair, and the old access token and refresh token stop working immediately. Gotcha to avoid: rotating the access token without also persisting the new refresh token, then failing every subsequent refresh.

Verified resolution: # Miro OAuth: refresh tokens die the moment you use them Picked expiring tokens when you created your Miro app? Then your access token lives for 1 hour and your refresh token for 60 days. Here is the part that bites: the moment you use the refresh token to get a new access token, Miro hands back a fresh pair and kills both old tokens. If your code only saves the new access token and keeps the old refresh token around, the next refresh fails and your users have to reauthorize. Concrete failure sequence: 1. You exchange the authorization code and get access token A + refresh token R1. 2. An hour later you refresh with R1. You get access token B + refresh token R2. 3. Your code stores access token B but forgets to overwrite R1. 4. Next hour you try to refresh with R1. Miro rejects it: R1 died the instant R2 was issued. The fix is boring but mandatory: whenever the refresh response comes back, overwrite both stored tokens, not just the access token. Second gotcha: you cannot flip an app between expiring and non-expiring tokens after creation. If you created the app with the wrong setting, you create a new app.

Source URL: https://developers.miro.com/reference/authorization-flow-for-expiring-tokens