Do Google refresh tokens expire?

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)?

Solution #1:

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.

Respondent: Shadow

Solution #2:

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.”

Respondent: Josh Hunter

Solution #3:

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.

Respondent: Amal Gunatilake

Solution #4:

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:

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.

Respondent: Roaders

Solution #5:

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.


Respondent: karl

Solution #6:

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

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.

Respondent: TonyE

Solution #7:

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.

Respondent: Shiven Ojha

Solution #8:

Read this from:
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.

Respondent: Jos Luijten

Solution #9:

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

Respondent: john fotouhi

Solution #10:

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.

Respondent: yebowhatsay

Solution #11:

I have done some further research and it seems that the Google access token is used to retrieve a refresh token, during the first ‘offline’ request. From, this point onwards, the refresh token is used to issue a new access token.
The idea is that an access token is a short term token, but it can be renewed by a long term refresh token. This removes the need for having to request the URL ‘code’ variable, which requires a two endpoint approach and has to be initiated, using a referrer based request:

Some, REST API services like Dropbox, issue access tokens that last forever, but Google issues short term access tokens. PayPal uses a compromise, whereby it allows access tokens to be retrieved without URI referrer enforcement. This means that access tokens can be retrieved without having to click on a link to initiate the process. Google’s methodology means that API routines should only be called on a need to use basis. Essentially, calls are initiated via referrer based procedures. This is controlled by issuing short-lived access tokens, or access tokens that must be refreshed in a chain.
This requires developers to think more carefully about how a system should flow.

Respondent: Charles Robertson

The answers/resolutions are collected from stackoverflow, are licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0 .

Leave a Reply

Your email address will not be published.