The payload portion of the JWT identifies the API account the request is for. It also includes timestamp information to limit the validity, and a nonce (as a "jti" value) to prevent replay attacks.
|Must be set to
|Identifies your API account (similar to a user name)
|UNIX timestamp of when the token was created, required if
exp is not present
|UNIX timestamp of when the token will be considered expired, required if
iat is not present
|JWT Token Id
|A unique token string, effectively a nonce, must be unique to each request, cannot be the empty string
UNIX timestamps are defined to be the number of seconds since midnight Jan 1, 1970 UTC. A JWT processed by the API MUST contain either the
iat (Issued At) and/or
exp (Expires) timestamps.
Every request must have a unique payload. The
jti value cannot be re-used*, even if the requested operation failed (400-599 HTTP status codes) or was incorrectly sent over HTTP instead of HTTPS.
For each request, it is recommended to generate a GUID or a sufficiently random string to ensure no two requests have the same
jti value within a 30 minute span.
A JWT is considered valid, if when received:
iat(if specified) is 3 minutes before or after (to account for clock skew) the current UTC time
exp(if specified) is less than 30 minutes in the future and the current UTC time is before
- If both
expare specified, both must pass and the time must be before whichever expires first
jtihas not been used before* for by
- The signature portion (HMAC) of the JWT is valid according to the RFC specification using the secret API key for
jti value can be reused after the original token would have expired, and thus the
exp would have to be different to be considered a valid token.