This article is useful for Unity, Unreal, and Core SDK developers who use Vivox Access Tokens and need to understand why a token is being rejected, including incorrect expiration values, device clock drift, or reusing expired tokens. It also explains recommended token generation practices, secure vending services, and when Unity Authentication tokens may be a better choice.
Symptoms
A Vivox SDK call requiring a Vivox Access Token (VAT) failed with status code 20121 "Access Token Expired".
Cause
There are three primary causes for a VxAccessTokenExpired (20121) error:
- The token expiration value has been set incorrectly when creating the access token. It's best practice to set the expiration to a fixed number of whole seconds past the current time. In production, we recommend creating access tokens with a 90 second expiration.
- The code to set the expiration time is set correctly, but the device clock on the machine generating the token is significantly behind the server time (after adjusting for timezone).
- The token is generated correctly, but is being used (or reused) after the expiration time. It is best practice to only vend tokens when you are ready to use them. Using (or reusing) a token after the expiration time will result in this error.
VxAccessTokenExpired (20121) rather than VxAccessTokenAlreadyUsed (20120)
Resolution
In production, Vivox Access Tokens should be generated from a secure token vending service, such as a central game server, when needed by the individual game clients. Client generated tokens should only be used for debugging during development before a vending service has been established. Generation of VATs on client devices can pose a security risk, but can also cause seemingly random expiration issues when the client device time is incorrect.
The following are examples of how to generate the expiration value 90 seconds past the current device time:
-
Unity:
TimeSpan.FromSeconds(90) -
Unreal:
FTimespan::FromSeconds(90) -
Core:
time(0L) + 90