Closed rmunn closed 6 months ago
On Sat, Jan 27, 2024 at 10:24:05PM -0800, Robin Munn wrote:
While trying to figure out why my Google OAuth sessions were expiring after one hour, I found https://github.com/pdobsan/mailctl/commit/c08c83c5d9d3c2022e9142474d94802822171d93 which has a comment about refresh tokens not being returned despite Google's documentation saying that they should be returned. That led
This comment refers to the process of renewal of the access token.
The refresh token is returned only once during the authorization step.
command-line parameter to the
authorize
command. If present, that parameter would add theprompt=consent
(and, if needed,
The prompt parameter is already given for the authorization step.
While trying to figure out why my Google OAuth sessions were expiring after one hour, I found https://github.com/pdobsan/mailctl/commit/c08c83c5d9d3c2022e9142474d94802822171d93 which has a comment about refresh tokens not being returned despite Google's documentation saying that they should be returned. That led me to find https://stackoverflow.com/a/65702100 where it's mentioned that for an app such as mailctl, you only get a refresh token immediately after the user has clicked "Allow" on the consent screen.
I ran
mailctl authorize google my_email@gmail.com --debug
and found that it was true: Google didn't show me a consent screen because mailctl was already authorized on my account, and the JSON returned from Google's OAuth endpoints did not contain arefresh_token
.The best solution, I think, would be to add a
--force-refresh-token
command-line parameter to theauthorize
command. If present, that parameter would add theprompt=consent
(and, if needed,access_type=offline
) parameters to the initialaccounts.google.com/o/oauth2/token
POST URL, to ensure that even if the user has already authorized the mailctl app, that Google will re-show the authorization screen and therefore mailctl will receive a refresh token.