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

OAuth2: How to check when only the refresh token is invalid #1515

Open
max-pod opened this issue Jan 15, 2023 · 0 comments
Open

OAuth2: How to check when only the refresh token is invalid #1515

max-pod opened this issue Jan 15, 2023 · 0 comments
Labels
priority: p3 Desirable enhancement or fix. May not be included in next release. type: question Request for information or clarification. Not an issue.

Comments

@max-pod
Copy link

max-pod commented Jan 15, 2023

Hey folks,

How can we check when the refresh token needs to get revalidated?
If these are the conditions that will cause it to expire:

      - The user has revoked your app's access
      - The refresh token has not been used for 6 months
      - The user changed passwords and the refresh token contains Gmail scopes
      - The user account has exceeded a max number of live refresh tokens
      - The application has a status of 'Testing' and the consent screen is configured for an external user type, causing the token to expire in 7 days

What code can we write as a check to see if the refresh token needs to be updated?

We tried to run getTokenInfo() but unless we want to update the accessToken right before an expired access token will just error, so the below throws if either the refresh_token or the access_token are invalid:

try {
    // This will should only throw if the refresh_token is invalid
    await oAuth2Client.getTokenInfo(googleOAuthToken.access_token)
  } catch (e) {
   //generate refresh url
}

We can simply run oAuth2Client.getAccessToken() every single time before getTokenInfo but that seems counterproductive to the efforts of the google team to make the access token revalidate automatically. We could also wrap every api request in a try/catch but that seems overly engineered.

@max-pod max-pod added priority: p3 Desirable enhancement or fix. May not be included in next release. type: question Request for information or clarification. Not an issue. labels Jan 15, 2023
@danielbankhead danielbankhead removed their assignment Jul 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: p3 Desirable enhancement or fix. May not be included in next release. type: question Request for information or clarification. Not an issue.
Projects
None yet
Development

No branches or pull requests

2 participants