Save `token_id` and `time_expires` from access token grant to credentials file

[david-crespo]

Fields added in oxidecomputer/omicron#8280, addressing oxidecomputer/omicron#8279.

Now that access tokens have generated ids that are used as the identifier in access token view/delete operations (introduced in #8227), it becomes hard to relate them with credentials.toml. For example, in the list token API response, the user sees only the tokens that haven't expired

$ oxide --profile recovery api /v1/me/access-tokens
{
  "items": [
    {
      "id": "6feec54c-6e3a-4c1a-9f82-8acd7a0ef249",
      "time_created": "2025-06-05T04:28:42.946403Z",
      "time_expires": null
    }
  ],
  "next_page": "eyJ2IjoidjEiLCJwYWdlX3N0YXJ0Ijp7InNvcnRfYnkiOiJpZF9hc2NlbmRpbmciLCJsYXN0X3NlZW4iOiI2ZmVlYzU0Yy02ZTNhLTRjMWEtOWY4Mi04YWNkN2EwZWYyNDkifX0="
}

But credentials.toml currently doesn't include the token id (and expired tokens aren't automatically removed from the file). So, it's posssible that user sees more tokens here:

[profile.recovery]
host = "https://recovery.sys.berlin.eng.oxide.computer"
token = "oxide-token-935212d5e41079cf0bcfc9ec84c0f8f7c09aac6b"
user = "8a705181-8afe-4604-86d6-06f4b5fac6e9"

[profile.recovery2]
host = "https://recovery.sys.berlin.eng.oxide.computer"
token = "oxide-token-c0187754418f8112ddf00b4767f546288f215ed8"
user = "8a705181-8afe-4604-86d6-06f4b5fac6e9"

When user wants to remove an expired token from the toml file or even to confirm which one should be used for certain requests, it's easy to make a mistake.

[ahl]

@askfongjojo you mentioned this in #1111, but I'm not clear what the request is regarding how the CLI would behave differently. Simply recording the token_id and time_expires doesn't seem particularly user-visible.

@david-crespo how would we associate a token with an an id? Is there some information we get during login? We currently pull the information out of CurrentUser and the ID for the token isn't there.

[david-crespo]

You can list all tokens with the current user access tokens endpoint. Saving time_expires and token_id from the grant response lets you do a couple of things:

• Friendly error when the token is expired because you know the reason for the 401
• Use the ID to power a command that lets the user kill the token for the current profile

I don’t know if users look at the TOML much (and I don’t remember if there’s a command to list all profiles) but even if you don’t do the above, just having the ID and expiration in the file is nice — it lets the user correlate what they see there with what’s listed on the my tokens page in the console.

[ahl]

It looks like perhaps token_id is some non-standard field. I think there's a way to adapt the oauth2 crate to get that information. What would we recommend for existing profiles?

[david-crespo]

You could hit the list endpoint with each token and fill in the info from there. Maybe an opt-in operation somehow?

Feel free to change the grant response if there’s a better way to include non-standard data. IIRC the spec doesn’t forbid it but also doesn’t recommend a way to do it.

[ahl]

You could hit the list endpoint with each token and fill in the info from there. Maybe an opt-in operation somehow?

The only time we get the token ID is when the token is first generated. Right? How would we get this token after the fact to correlate them with existing tokens?

Feel free to change the grant response if there’s a better way to include non-standard data. IIRC the spec doesn’t forbid it but also doesn’t recommend a way to do it.

I don't know how we would change the response to be more useful.

---

Also, let's say we do record the ID and expiration time ... then what? What if the administrator changes the timeout? This would just appear like a token that doesn't work, but whose expiration time is still in the future. I'm not sure how to use this interface.

[askfongjojo]

The only time we get the token ID is when the token is first generated. Right? How would we get this token after the fact to correlate them with existing tokens?

There aren't good ways to do so. For silo admins who want to start configuring a token TTL when there are already users who having never-expired token, they'll have to enforce some kind of token cleanup. If it's a brand new silo and the admins are the only users who have existing API tokens (like in the case of the customer asking to expedite this feature), there shouldn't be any need to reconcile with existing tokens.

What if the administrator changes the timeout?

The current design doesn't allow changing the timeout of existing tokens by admins; instead, we'll provide them the ability to delete/revoke user tokens in r16. When users create new tokens, the TTL will take effect.