OAuth out-of-band token deprecation

[theastroventure]

I have received an email from Google that they are deprecating this method of obtaining access tokes for OAuth. I believe this is the method recommended in the README for this project. More details at the blog post here: https://developers.googleblog.com/2022/02/making-oauth-flows-safer.html.

I'm wondering if you have new guidance on how to obtain access tokens in order to use this project that fit the new guidelines. I've tried looking through the blog post recommendations and the links they provide, but everything I saw was for requesting access for a user rather than obtaining a token for our own account.

[xdekasx]

I have the same question. Have you found some fix?

The REDIRECT_URI I see in this project matches with the shown in the Google blog page so I understand that the package should be updated to continue being use after the deprecation ( Correct me if I'm wrong ).

Maybe this link can be useful to migrate from OOB. https://developers.google.com/identity/protocols/oauth2/resources/oob-migration

This module will be updated?

Thanks,

[theastroventure]

Unfortunately, I don't have a solution to this yet. I've put off looking into it hoping for a response here, but I will be looking into it in the next month or two and post anything I find here. Thanks for the link, I'll start by looking into that.

[xdekasx]

Finally, as my project only need to send few emails I have stopped using this module and change the delivery of mails using an App password provided by Google until I find a better way to handle this.

Hope you find a fix.

[dolfim]

Hi guys, indeed this doesn't sound promising for the approach taken in the package. Let's see if we come up with alternatives.

Maybe this link can be useful to migrate from OOB. https://developers.google.com/identity/protocols/oauth2/resources/oob-migration

This migration guide suggests using a redirect_uri to localhost. One could think of a simple web server to receive once the refresh_token, and then the token update should work as before. However, when clicking on the link in the documentation, it seems the loopback address flow is also going to be deprecated (even earlier). Given that we don't look for a constant authentication using localhost, but only once to obtain the refresh_token, we might still be good to go.

[dolfim]

Checking the loopback ip redirect. The deprecation notice is actually only for mobile devices

Loopback IP address flow will be disallowed for native iOS, Android and Chrome OAuth client types Reference: https://developers.googleblog.com/2022/02/making-oauth-flows-safer.html#disallowed-loopback

[theastroventure]

@dolfim Have you had a chance to test a solution using that method?

Looking through the migration guide, it looks like they don't have a good use case for an application requesting long running permission. The only solution I see that looks relevant is: https://developers.google.com/identity/protocols/oauth2/web-server, but that requires the user (us) to manually sign into our Google account and approve. I don't know how long that would last. If it does last, presumably we could rewrite this library to use that flow and rewrite the documentation to have us go through a local setup with flask to grab the token from step 4 at that link. Re: duration: it may last longer if we use: https://developers.google.com/identity/protocols/oauth2/web-server#offline

Does anyone have GCP customer support access? My company does not currently pay for it, and it seems the only way we could open a ticket to ask for how to support this workflow (since it seems to not be directly supported in the documentation Google has sent us).

[theastroventure]

@xdekasx were you successful using an app password? I switched from using an app password a couple of years ago to this package because Google sent me an email saying they were no longer allowing app passwords.

Edit: I spoke to a support person with Google Workspace, and he told me that app passwords still work because too many folks were using them for Google to shut down that method of authentication. They still consider it unsafe and they would like to deprecate it, but they don’t have a timeline yet.

He sent me some information about how to possibly authenticate using impersonation in order to continue using this library, but I’m not convinced it is an easy fix. Unfortunately, it doesn’t seem as though Google has an easy way to solve this problem.

I’m going to try moving back to the app password, and if it does get deprecated in the future, I’ll probably move to a paid service.

[xdekasx]

@theastroventure At the moment I haven't have any problem using password. :+1:

[DrPeeps]

Guys, does this package still work in 2023 due to the OOB deprecation described above? I seem to be getting an error now when I try to generate a new refresh token with the gmail_oauth2 script.

Could using a Service Account be a better option for this package? (I'm very new at this...): https://developers.google.com/identity/protocols/oauth2/service-account

[samueldy]

Google has this Python quickstart code for the Gmail API: https://developers.google.com/gmail/api/quickstart/python#configure_the_sample.

Google's Python SDK will run a local server to listen for the verification code, which is what is required now that OOB flows are gone.