Hey folks,
We’re trying to rotate our OAuth client secret for a high-traffic integration without causing any drop in active sessions. The current setup uses the standard client credentials grant to pull a token every hour. The issue is that if we update the secret in the Genesys Cloud portal, all existing tokens tied to the old secret get invalidated immediately. That kills every active call and data sync we have running.
I’ve read the docs on rotating secrets, but they don’t really cover the race condition where a service is mid-request when the switch happens. We’re thinking of using the POST /api/v2/oauth/clients/{id}/secrets endpoint to add a new secret alongside the existing one, then gradually shifting traffic.
Here’s the flow we’re testing:
- Generate new secret via API.
- Update our config store to use the new secret for new token requests.
- Wait for old tokens to expire (1 hour).
- Delete old secret.
The problem is step 2. If we have multiple microservices, they won’t all pick up the new secret at the exact same millisecond. Some services will try to use the old secret after we’ve supposedly moved on, or worse, they might get a 401 Unauthorized if we delete the old one too early.
Is there a way to keep both secrets active indefinitely? Or do we need to implement a fallback logic in our code to catch the 401 and retry with the new secret?
We’re using the Python SDK (genesyscloud). Right now, the token refresh logic looks like this:
def refresh_token(client_id, client_secret):
return genesyscloud.auth.auth_api.get_client_credentials_token(
client_id,
client_secret,
grant_type='client_credentials'
)
If I swap client_secret in the environment variables, does the SDK handle the transition gracefully, or do I need to manage a pool of secrets? We’ve seen intermittent 401s during our last attempt, which suggests the old token wasn’t fully expired before the new one was required.
Any thoughts on how you’ve handled this in production? We don’t want to restart the whole service just to pick up a new secret.