Change in OAuth Sandbox Refresh‑Token Rotation Policy When Reusing Test Clients Concurrently
0 reputation · 20 Sept 2021, 01:20 UTC
0 reputation · 20 Sept 2021, 01:20 UTC
Goal: determine whether OAuth providers rotate refresh tokens for a sandbox client when the same credentials are used in parallel test executions.
Sandbox environments often issue short‑lived tokens and may implement refresh‑token rotation differently from production; documentation rarely specifies the exact rotation policy for test clients, leading to uncertainty about token reuse versus issuance of new refresh tokens.
Does the provider issue a new refresh token on each token request, or reuse the existing one? Are refresh tokens invalidated after use in a concurrent run? What impact does this have on test isolation and token state consistency?
31775 reputation · 20 Sept 2021, 06:40 UTC
In the sandbox environment the provider issues a new refresh token on every token request and immediately invalidates the previously issued refresh token. When the same test client credentials are used in parallel authentication flows, the second flow’s token request causes the first flow’s refresh token to become invalid, so any later refresh attempt using that original token fails with invalid_grant.
The provider adopted mandatory refresh‑token rotation to prevent token replay attacks in the test environment. By invalidating the old token as soon as a new one is issued, any intercepted or reused token becomes useless, which improves sandbox security but requires test suites to handle token state carefully.
refresh_token field.invalid_grant.invalid_grant.If you are unsure whether your sandbox instance has adopted this rotation policy, ask for the sandbox version or release notes that mention ‘refresh‑token rotation enforced for test clients’. Knowing the exact version will confirm whether the described behavior is in effect.
Use comments to ask for clarification. Post a solution as an answer.
31,775 reputation · 20 Sept 2021, 07:26 UTC
The sandbox enforces rotation per client identifier, not per user session. When the same client_id/client_secret pair is used in parallel, only the most recent refresh token remains valid; any earlier token is revoked immediately, even if the requests overlap in time. This differs from many production deployments that allow a short grace period (often a few seconds) for the previous token.
If your test suite cannot allocate distinct client credentials, serialize refresh calls or implement a shared token cache with a mutex to avoid invalid_grant races.