Google Api Refresh Token Clarification

Question

I get an Access Token & a Refresh Token from an Android App using a Post Request, i have read somewhere that the Refresh Token never expire & then i've seen that there is a Limit of 25 Refresh Token issued,

What is the meaning of this in the Google Developer Doc :

"Note: Save refresh tokens in secure long-term storage and continue to use them >as long as they remain valid. Limits apply to the number of refresh tokens that >are issued per client-user combination, and per user across all clients, and these limits are different. If your application requests enough refresh tokens >to go over one of the limits, older refresh tokens stop working."

1. Limit apply to Refresh Token > Get Access Token Operation ?
2. Limit apply to Prompt User > Get Refresh Token Operation ?

That's mean a user could use the Google Api on 25 Device Max. ? & what if the user use the same Account on +25 Devices ?

I Plan to have a Background Service which once started, will automatically get an Access Token using the Refresh Token saved to ensure to have always a valid Token,

Thanks for your Clarification

Answer 1

1. This is not a problem. If a refresh token is not used for six months, it will become invalid, but using your refresh token to get a new access token can be done indefinitely, in theory.

2. This is the main problem. If you store the refresh token on the device of your users, and a user has 26 devices for some reason, the refresh token on the first device will become invalid once you get the 26th one.

In closing, it is good to have some fallback code for when a refresh token stops working for some reason, and re-prompt the user. The user might not use the device for six months, he might revoke the app's access or it might stop working for any other reason.

Answer 2

If you continue reading the Token Expiration section of this Google OAuth2 document, you can see the answer you need. Google indicates a few key things to consider in your application's architecture:

• Refresh tokens are issued per client + user. This means for a given app, each user per client they can be issued 25 refresh tokens.

  • Limit the number of clients you authorize to 15 or 20 within your application code to prevent dropping refresh tokens previously issued for that particular client-user (oldest dropping off first)

  • Refresh tokens begin to drop off the tail end of available refresh tokens for a given client once the threshold of 25 has been exceeded

• The threshold does not apply to service accounts, which you may wish to use for a backend application which does not have a client-facing UI. These are typically server-side ONLY applications which automate processes such as: data transfer, data sync/reconciliation, etc...

I would review the examples and documentation for your use case which are provided in the link above to better understand how to solve the problem for the appropriate app type: web server, client-side, or installed.

Additionally, I would highly recommend using one if their Client Libraries (available at the bottom of the page in the link above) since that should help to simply implementation.