auth: expose AccessToken expiration

Open
  • Is something wrong?
#7,410 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
authentication, backend-api-design

Research direction

Start by reading src/auth/src/token.rs and src/auth/src/credentials.rs, especially the token expiry tracking and conversion linked in the issue. Review #7391 and the semver concern described here to understand the proposed API shape. Done means callers can obtain the token and its optional expiration without adding a breaking field to AccessToken; add or update focused auth tests for known and unknown expirations.

Written by the indexing model from the issue text.

Description

auth priority: p3 type: feature request

Is your feature request related to a problem? Please describe.
I have a short-lived CLI that needs an access token on every run. It keeps the token in a private file between runs (much like gcloud's own token cache), so it needs to know when the token expires.

AccessToken only exposes token. The SDK tracks the expiry internally but drops it in the conversion, so the CLI can't get the lifetime from the SDK. Today it gets tokens from gcloud auth print-access-token and looks up the lifetime with the tokeninfo endpoint after each fetch.

Describe the solution you'd like
A way to get the expiration along with the token, or None when it isn't known. This was part of the original sketch in #2929, and #7391 implements it as a field. An Instant is fine for my use; I'd convert it to wall-clock time when saving.

One semver note: AccessToken has only public fields and isn't #[non_exhaustive], so adding any field, even a private one behind an accessor, breaks struct-literal construction (for example in mocks of AccessTokenCredentialsProvider). cargo-semver-checks reports that as major (constructible_struct_adds_private_field). A new method that returns a #[non_exhaustive] type with the token and its expiry would leave AccessToken unchanged.

The other Google auth libraries already expose this:

Describe alternatives you've considered

  • Looking up tokeninfo after each fetch (current workaround): an extra request per token.
  • Assuming a one-hour lifetime: unsafe, since lifetimes vary by credential type.
  • Fetching a fresh token in every process: works, but adds a token request to every run.

Additional context
On #7391 there was a question of whether this needs to be exposed at all. This is a case where the SDK's in-process cache can't help: the process exits before the token could be reused.

Dominant language
Rust
Stars
972
Forks
163
Avg merge
1d 13h
Merged PRs (30d)
202

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from googleapis/google-cloud-rust

All issues in googleapis/google-cloud-rust

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.