token-vendor rejects token if clock is slightly fast

[drigz]

I don't have a good repro for this as I've only seen it on systems that were offline for a while. The token-vendor rejects the request with:

{
  "timestamp": "2024-03-15T10:50:25.236896019Z",
  "severity": "ERROR",
  "source": {
    "function": "github.com/googlecloudrobotics/core/src/go/cmd/token-vendor/api/v1.(*HandlerContext).tokenOAuth2Handler",
    "file": "src/go/cmd/token-vendor/api/v1/v1.go",
    "line": 245
  },
  "message": "unable to retrieve cloud access token with given JWT",
  "Error": "failed to verify signature for device \"robot-my-robot\": failed to parse and verify signature: Token used before issued"
}

I don't know how far the clocks were out-of-sync at this point, but it fixed itself within a few minutes. I guess it could be tested with a local cluster, disabling NTP and setting the time a few seconds into the future, then restarting gcr-credential-refresher to trigger a token exchange - but haven't tried this.

We are using github.com/form3tech-oss/jwt-go to verify without any special options:

https://github.com/googlecloudrobotics/core/blob/9f495fd374e9b38cda61fe479323d04a9b70a1aa/src/go/cmd/token-vendor/oauth/jwt/jwt.go#L47

This repo was archived on Aug 10, 2021 - @csieber do you know if there's a reason we didn't use https://github.com/golang-jwt/jwt from the start? The new library has an option for specifying leeway for clock sync when parsing/validating tokens: https://pkg.go.dev/github.com/golang-jwt/jwt/v5#WithLeeway https://github.com/golang-jwt/jwt/blob/80dccb9209ebe7b503c067dc830fcbd4aa2e74eb/validator.go#L37