Does the quick-start Python Gmail API code handle refresh tokens?

1
votes

Does this quick-start code handle refresh tokens? If so, where/how?

https://developers.google.com/gmail/api/quickstart/quickstart-python

I am working on a Python application that needs to have continuous/unfettered access to Gmail account emails, so I want to make sure that I am handling the scenario described on this page:

https://developers.google.com/gmail/api/auth/web-server#send_authorized_requests_and_check_for_revoked_credentials

Specifically, the "If your application requires offline access, the first time your app exchanges the authorization code, it also receives a refresh token that it uses to receive a new access token after a previous token has expired. Your application stores this refresh token (generally in a database on your server) for later use" paragraph.

It's not clear to me if/how this is handled by the quick-start code. Thanks!

2
pythongmail-api

2 Answers

1
votes

I figured this out. The refresh token, if saved for offline access by the application, is used to perpetually request new access tokens (as they are short lived/expire). This quick-start code does save the refresh token in the stored credentials (the STORAGE file) and wraps the Oauth 2.0 methods that get new access tokens from the authorization server when needed.

If for some reason you need to get another refresh token, you can request one from the authorization server, after making the user to approve your application again:

From https://developers.google.com/gmail/api/auth/web-server "Always store user refresh tokens. If your application needs a new refresh token it must sent a request with the approval_prompt query parameter set to force. This will cause the user to see a dialog to grant permission to your application again."

More info about authorization server requests: https://developers.google.com/accounts/docs/OAuth2WebServer

0
votes

Just to add,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.