Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add eagerRefreshThresholdMillis parameter to the IdTokenClient to prevent getting invalid token on getRequestHeaders #1358

Open
dstacko opened this issue Feb 7, 2022 · 0 comments
Labels
next major: breaking change this is a change that we should wait to bundle into the next major version priority: p3 Desirable enhancement or fix. May not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@dstacko
Copy link

dstacko commented Feb 7, 2022

Hi,
Is your feature request related to a problem?.
Yes, we are using the library to make http calls to a GCP Cloud Run service with the IdTokenClient. But sometimes, we have a 401 because the token is expired.
After investigation, those 401 occure when the token is about to expire. The root cause is a clock delay on the system calling system.

Describe the solution you'd like
We want to be hable to pass a parameter, like eagerRefreshThresholdMillis in OAuth2Client , to force refresh token x millisecond before the end.

Describe alternatives you've considered
To mitigate the issue, we have overrided the getRequestMetadataAsync in IdTokenClient to take into account a custom eagerRefreshThresholdMillis at this line .

Additional context
We create the client with googleAuth.getIdTokenClient(targetAudience) and get the token (auth headers) with getRequestHeaders

@dstacko dstacko added priority: p3 Desirable enhancement or fix. May not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. labels Feb 7, 2022
@d-goog d-goog added the next major: breaking change this is a change that we should wait to bundle into the next major version label Jan 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
next major: breaking change this is a change that we should wait to bundle into the next major version priority: p3 Desirable enhancement or fix. May not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
Development

No branches or pull requests

2 participants