We’re trying to rotate the OAuth client secret for our custom agent desktop app without dropping active sessions. The standard flow is to create the new secret, update the app config, then delete the old one. Seems straightforward in theory.
The issue is the timing. We’ve got a few hundred agents logged in. When we switch the secret in the app’s config.json and restart the service, the existing access tokens are still valid, but the refresh token flow starts failing immediately.
Here’s the sequence:
- We generate a new client secret via
POST /api/v2/oauth/clients/{clientId}/secrets. - We update the app’s environment variables.
- We restart the client app.
The app uses the genesys-cloud-auth SDK wrapper. When an agent’s access token expires and the SDK tries to refresh it using the stored refresh token, it hits POST /api/v2/oauth/token with grant_type=refresh_token.
If the refresh request happens before the client app fully loads the new secret, or if there’s a race condition where the token service hasn’t fully propagated the new secret validation, we get a 401 Unauthorized with error: invalid_grant.
We’ve tried staggering the restarts, but it’s messy. Is there a way to force the SDK to prioritize the new secret for the refresh call without a full restart? Or is there a specific header we need to pass to the token endpoint to hint at the secret version?
Here’s the error payload we’re seeing in the console:
{
"error": "invalid_grant",
"error_description": "The refresh token has been revoked or is expired."
}
It feels like the refresh token is tied to the old client secret hash. If that’s the case, rotating secrets inherently invalidates refresh tokens, which means a full re-auth for every user. That’s not downtime, but it’s annoying.
Has anyone found a way to keep the refresh tokens valid during the secret swap? We’re using genesys-cloud-platform-client version 3.4.2.