checkcred json output issues

[erzhan46]

PROBLEM SUMMARY
There are couple issues with checkcred json format output:

• Incorrect expiration date - looks like it shows grant/refresh expiration instead of token expiration.
• Timestamps returned in ISO8601 format, whereas 'getcred' option displays it in unix timestamp / epoch format. (This makes it harder to implement scripting / automations logic)

E.g.:

# vcert getcred  --username <REMOVED>   --password <REMOVED>    -u <REMOVED>   --client-id <REMOVED>   --scope "certificate:manage" --platform TPP --no-prompt --format json
{
    "access_token": "<REMOVED>",
    "expires": 1727704116,                 <- This is expiration timestamp 2024-09-30T13:48:36Z
    "expires_in": 7776000,
    "identity": "<REMOVED>",
    "refresh_token": "<REMOVED",
    "refresh_until": 1751464116,        <- This is grant/refresh expiration timestamp 2025-07-02T13:48:36Z
    "scope": "certificate:manage",
    "token_type": "Bearer"
}

# vcert checkcred --token '<REMOVED>' -u <REMOVED> --format json
vCert: 2024/07/02 13:49:01 Warning: --platform not set. Attempting to best-guess platform from connection flags
{
    "access_issued_on_ISO8601": "2024-07-02T13:48:35Z",
    "application": "<REMOVED",
    "expires_ISO8601": "2025-07-02T13:48:35Z",    <- This should be token expiration, but it shows grant expiration 
    "grant_issued_on_ISO8601": "2024-07-02T13:48:35Z",
    "identity": "<REMOVED>",
    "scope": "certificate:manage",
    "valid_for": 7776000
}

STEPS TO REPRODUCE
Run vcert getcred and vcert checkcred with --format json option.

EXPECTED RESULTS

• checkcred --format json "expires" field shows token expiration
• checkcred --format json timestamp fields shows all results in unix timestamp format

ACTUAL RESULTS

• checkcred --format json "expires" field shows grant expiration instead of token expiration
• checkcred --format json timestamp fields shows all results in ISO8601 format

ENVIRONMENT DETAILS
Venafi vcert v.5.6.4

COMMENTS/WORKAROUNDS

[luispresuelVenafi]

Hi there @erzhan46 , thank you for reaching out!

Incorrect expiration date - looks like it shows grant/refresh expiration instead of token expiration.

What do you mean here? The token validity, effectively is the grant validity; once the grant is expired, the token is not valid anymore as well, thus you need to get a new access token. Not sure if I'm missing something. Could you elaborate more if you think my answer doesn't apply?

Timestamps returned in ISO8601 format, whereas 'getcred' option displays it in unix timestamp / epoch format. (This makes it harder to implement scripting / automations logic)

This timestamp was by designed for most currently scripting scenarios that our customers use, thus this behavior is expected (not a bug).
It'd, definetely, be good to have a way to specify different formats for the timestamp returned value, but this would be an enhancement.

I'll be removing the "bug" tag as these issues seems more to be "question" and "enhacenment" types.

[erzhan46]

Hi @luispresuelVenafi

My understanding is there are two expiration timestamps:

• Token expiration - amount of time access token can be used to e.g. request certificates.
• Token refresh/grant - amount of time refresh token can be used to refresh actual access token.
  E.g.:

# vcert checkcred --token ${OAUTH_TOKEN} -u ${SDK_URL} 
vCert: 2024/07/02 14:41:51 Warning: --platform not set. Attempting to best-guess platform from connection flags
vCert: 2024/07/02 14:41:51 Checking credentials...
access_token_expires:  2024-09-30T13:48:35Z      <- Access token expiring in 90 days
grant_expires:  2025-07-02T13:48:35Z                     <- Refresh/grant token expiring in one year.
client_id:  <REMOVED>
scope:  certificate:manage

So in checkcred json output - in expires_ISO8601 field it shows refresh/grant token expiration (one year).
What I'm asking here is consistency - in free text output - checkcred shows both access and refresh/grant token expirations, whereas in json output - it shows only some generic 'expires' field with refresh/grant token expiration and doesn't show at all when access token will expire.

The problem with timestamps I have is that getcred in json format outputs them in Unix timestamp whereas checkcred in json format outputs them in ISO8601 format. What I'm asking here again is some consistency. From scripting/automation point of view I think unix timestamp will be more convenient, but any format will work as long as it's the same.

[luispresuelVenafi]

My understanding is there are two expiration timestamps...

Indeed there are, but unfortunately, the access_token timestamps itself is not returned in the API response, only the validity:
https://docs.venafi.com/Docs/currentSDK/TopNav/Content/SDK/AuthSDK/r-SDKa-GET-Authorize-Verify.php?Highlight=vedauth%2FAuthorize%2FVerify

Which is what we return in JSON format (valid_for for access_token and expires_ISO8601 for refresh_token). Unlike the text version, where we do calculate the timestamp itself for the access_token:

...
iso8601fmt := "2006-01-02T15:04:05Z"
tm, _ := time.Parse(iso8601fmt, resp.AccessIssuedOn)
accessExpires := tm.Add(time.Duration(resp.ValidFor) * time.Second).Format(iso8601fmt)
fmt.Println("access_token_expires: ", accessExpires)
...

The problem with timestamps I have is that getcred in json format outputs them in Unix timestamp whereas checkcred in json format outputs them in ISO8601 format. What I'm asking here again is some consistency. From scripting/automation point of view I think unix timestamp will be more convenient, but any format will work as long as it's the same.

Yeah, adding this consistency would be an enhancement. As well as adding (calculating) the value for JSON version of the command.

[erzhan46]

Thank you for explanation.

Between timestamps in checkcrd output returned in ISO8601 format and the fact that access token expiration is not calculated in json output - it makes it somewhat hard to calculate token expiration e.g. if I use it in shell scripts.

Thanks again!