Tempo requires redirect_uri on the refresh_token grant. RFC 6749 does not define that parameter for this grant — it belongs to the authorization code exchange, where it prevents redirect manipulation. A refresh involves no redirect, so the parameter carries no security value there.
The consequence is that any client built on a standards-compliant, generic OAuth2 implementation cannot refresh a Tempo token at all. Such clients deliberately offer no way to add non-standard parameters to the refresh call. n8n's generic OAuth2 credential is one example, and the same applies to many OAuth libraries and low-code integration platforms.
In our case a daily Jira/Tempo reporting job ran for weeks and then stopped. What remains are two workarounds, both worse than a standard refresh: implementing the refresh by hand, which pulls the client secret and a rotating refresh token into the workflow, or a static API token that expires after a year and has to be renewed manually.
Why you should do this: accepting redirect_uri as optional on the refresh grant removes an interoperability barrier for every no-code and low-code platform, at no security cost and with no breaking change — clients that already send it keep working unchanged. It is one validation rule, and it makes Tempo work out of the box wherever standard OAuth2 does.
Alex Ziegltrum
| Tempo Platform | Cloud |
