Do Google refresh tokens expire?

The Google Auth server issued Refresh tokens never expire — that's the whole point of the refresh tokens. The refresh token will expire (or I should say become unauthorized) when the user revokes access to your application.

Refer this doc it clearly states the function of refresh tokens.

Instead of issuing a long lasting token (typically good for a year or unlimited lifetime), the server can issues a short-lived access token and a long lived refresh token. So in short you can use refresh tokens again and again until the user who authorized the access revokes access to your application.

This is a very confusing thread. The first answer appears to be right, but doesn't actually cite anything authoritative from google.

The most definitive answer I found is actually in the developer's playground where you obtain the token. Step 2 has a note at the bottom that says:

"Note: The OAuth Playground does not store refresh tokens, but as refresh tokens never expire, user should go to their Google Account Authorized Access page if they would like to manually revoke them."

https://developers.google.com/oauthplayground/

I experienced the same issue and later found out the mistake I was doing. Posting it here so that someone else might find it useful too.

The following can be read from the Google document Using OAuth 2.0 to Access Google APIs, the section Refresh token expiration:

A Google Cloud Platform project with an OAuth consent screen configured for an external user type and a publishing status of "Testing" is issued a refresh token expiring in 7 days.

Refresh tokens will actually expire after 7 days if the project publishing status is "testing". Per google documentation:

A Google Cloud Platform project with an OAuth consent screen configured for an external user type and a publishing status of "Testing" is issued a refresh token expiring in 7 days.

Link to quote

I don't think that is completely true:

Note that there are limits on the number of refresh tokens that will be issued; one limit per client/user combination, and another per user across all clients. You should save refresh tokens in long-term storage and continue to use them as long as they remain valid. If your application requests too many refresh tokens, it may run into these limits, in which case older refresh tokens will stop working.

from this page: https://developers.google.com/youtube/v3/guides/authentication#installed-apps

That is from the youTube docs (which I find to be much better than other api docs) but I think it is the the same across all google apps.

The rules have changed on this sometime in 2017, so the best answer I think is that it depends on the product. For example, on the Gmail API, the Oauth 2.0 refresh token expires upon password change. See this https://support.google.com/a/answer/6328616?hl=en

We used to setup API access in advance and generate refresh tokens when we setup NEW gmail users, and then we could archive their mail (we are required to do so by law), but now as soon as they change their password, the refresh token is revoked.

Perhaps for youtube, maps, the refresh token is still truly long lived, but for gmail api, count on a short token.

see this:

Refresh tokens are valid until the user revokes access. This field is only present if access_type=offline is included in the authorization code request.

in https://developers.google.com/accounts/docs/OAuth2WebServer

Read this from: https://developers.google.com/identity/protocols/oauth2#expiration You must write your code to anticipate the possibility that a granted refresh token might no longer work. A refresh token might stop working for one of these reasons:

The user has revoked your app's access. The refresh token has not been used for six months. The user changed passwords and the refresh token contains Gmail scopes. The user account has exceeded a maximum number of granted (live) refresh tokens. There is currently a limit of 50 refresh tokens per user account per client. If the limit is reached, creating a new refresh token automatically invalidates the oldest refresh token without warning. This limit does not apply to service accounts.

There is also a larger limit on the total number of refresh tokens a user account or service account can have across all clients. Most normal users won't exceed this limit but a developer's test account might.

For personal projects, simply submit the app on Google Console 'Oauth Consent Screen' tab for verification to stop tokens from expiring. No need to do anything further if you don't want the app to be verified.

The main concept of the refresh token is that it is long-lasting and never expires.

The access token has an expiry time and it expires, once it expires we can go for the refresh token, that will be used again and again until the user revokes from his account.

Set a long expiration time for OAuth tokens

Setting a long expiration time for an access token and/or refresh token in the OAuthv2 policy leads to accumulation of OAuth tokens and increased disk space use on Cassandra nodes.

The following example OAuthV2 policy shows a long expiration time of 200 days for refresh tokens:

<OAuthV2 name="GenerateAccessToken">
<Operation>GenerateAccessToken</Operation>
<ExpiresIn>1800000</ExpiresIn> <!-- 30 minutes -->
<RefreshTokenExpiresIn>17280000000</RefreshTokenExpiresIn> <!-- 200 days -->
<SupportedGrantTypes>
  <GrantType>password</GrantType>
</SupportedGrantTypes>
<GenerateResponse enabled="true"/>

link here

In the above example:

The access token is set with a reasonably lower expiration time of 30 mins.

The refresh token is set with a very long expiration time of 200 days.

If the traffic to this API is 10 requests/second, then it can generate as - many as 864,000 tokens in a day.

Since the refresh tokens expire only after 200 days, they persist in the data - store (Cassandra) for a long time leading to continuous accumulation.