We are building a custom agent desktop extension using the .NET SDK. The app runs on the client machine, but it hits our internal gateway before reaching Genesys Cloud. Everything works fine for the first hour. Then the access token expires. The SDK triggers a refresh automatically. The refresh token is valid. The new access token comes back with a 200 OK from the auth endpoint.
The problem happens immediately after. The SDK takes that new token and tries to call /api/v2/users/me. The request fails with a 401 Unauthorized. The response header says WWW-Authenticate: Bearer error="invalid_token".
I logged the token claims. The exp time in the new JWT is exactly one hour from the time the refresh happened. My local machine time is synced via NTP. The Genesys Cloud servers are also synced. But there is a 45-second difference between my machine clock and the time the Genesys auth server stamped the token.
Here is the code where I initialize the client:
var client = new PlatformClient();
client.AuthenticationManager.AuthenticationClient = new CustomAuthClient();
client.SetAuthCredentials(new AuthCredentials
{
ClientId = "my-client-id",
ClientSecret = "my-secret",
AuthUrl = "https://api.mypurecloud.com/oauth/token"
});
I am not storing the token myself. The SDK handles the refresh. But it seems the SDK sends the new token to the API gateway before the gateway’s clock has caught up to the token’s iat (issued at) time. Or maybe the gateway is strict about the nbf (not before) claim.
I tried adding a 5-second delay after the refresh event before making the next API call. That fixes it. But that is a hack. The SDK should handle this. Is there a property on PlatformClient or AuthCredentials to add a clock skew tolerance? I don’t see one.
The error log shows the token is valid according to the SDK, but the API rejects it. It feels like a race condition between the token issuance and the API validation clock. We are on US/Pacific time. The servers might be UTC. The drift is small but consistent.
Does anyone know how to configure the .NET SDK to tolerate a 60-second clock skew? Or is this a bug in the token validation logic?