Do Google refresh tokens expire?

Question

I have used the refresh token several times in just a short period for testing purposes, but I wonder whether Google refresh tokens ever expire? Can I use the same refresh token to get another access token again and again for a long period (a week or even months)?

Answer 1

This has changed for Gmail. In an eMail from GoogleDevelopers-noreply@google.com:

You have indicated that your app has features related to “email reporting and monitoring”, as defined in the Gmail user data and developer policy. This is specified in the Google Cloud Platform Console under the Scopes section of the OAuth consent screen page. We would like to remind you that starting June 3, 2024, apps that use information from emails to provide reporting or monitoring services will require periodic Gmail access renewals. This change helps protect privacy and security for new and existing users.

Answer 2

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.

Answer 3

FWIW, I successfully used the OIDC (OpenID Connect) token in a similar situation, where Google Could Tasks were created in the queue and supposed to be run days after creation. The problem was that all the tasks ran up to one hour but failed after that.

Sample code:

from google.cloud import tasks_v2

headers = {'Content-Type': 'application/json',
                'Accept': 'application/json'}

task = {'http_request': 
            {  
                'http_method': tasks_v2.HttpMethod.POST, # Specify the type of request
                'url': 'https://REGION-PROJECT_ID.cloudfunctions.net/FUNCTION_NAME',  # The full url path that the request will be sent to.
                'headers': headers,
                'oidc_token': {
                    'service_account_email': 'your-service-account@your-project-id.gserviceaccount.com'
                },
                'body': b'{"message": "Hello, World!"}'  # The payload of the HTTP request.
            }
        }

This configuration tells Cloud Tasks to fetch a fresh ID token for the service account just before making the HTTP call.

Answer 4

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.

Answer 5

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

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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/

Answer 12

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

Answer 13

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.