email from Google: [Action Required] Migrate your OAuth out-of-band flow to an alternative method before Oct. 3, 2022

[nikant]

received this.. any ideas what we should change in order to keep gmvault working?

In .conf there is a line that refers to oob

# Hardcoded dummy redirect URI for non-web apps. redirect_uri=urn:ietf:wg:oauth:2.0:oob

email:

Our records indicate you have OAuth clients that used the OAuth OOB flow in the past.
Hello Google OAuth Developer,

We are writing to inform you that OAuth out-of-band (OOB) flow will be deprecated on October 3, 2022, to protect users from phishing and app impersonation attacks.

What do I need to know?
Starting October 3, 2022, we will block OOB requests to Google’s OAuth 2.0 authorization endpoint for existing clients. Apps using OOB in testing mode will not be affected. However, we strongly recommend you to migrate them to safer methods as these apps will be immediately blocked when switching to in production status.

Note: New OOB usage has already been disallowed since February 28, 2022.

Below are key dates for compliance

September 5, 2022: A user-facing warning message may be displayed to non-compliant OAuth requests
October 3, 2022: The OOB flow is blocked for all clients and users will see the error page.
Please check out our recent blog post about Making Google OAuth interactions safer for more information.

What do I need to do?
Migrate your app(s) to an appropriate alternative method by following these instructions:

Determine your app(s) client type from your Google Cloud project by following the client links below.
Migrate your app(s) to a more secure alternative method by following the instructions in the blog post above for your client type.
If necessary, you may request a one-time extension for migrating your app until January 31, 2023. Keep in mind that all OOB authorization requests will be blocked on February 1, 2023.

The following OAuth client(s) will be blocked on Oct 3, 2022.

OAuth client list:

Project ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Client: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thanks for choosing Google OAuth.

— The Google OAuth Developer Team

[TcT2k]

Got the same message, would also be interested to know what to change. gmvault has been running without issues for me for years, so it would be great to be able to continue to use it.

[gboudreau]

Apps using OOB in testing mode will not be affected.

I'm pretty sure that means that if your OAuth consent screen Publishing status is Testing, you're OK. Having a Publishing status In production requires having Google review (verify) your (OAuth) app, and I don't think we need (or want) that for Gmvault.

Of note: if you created your OAuth consent screen a long time ago, I think 7+ years ago, then your consent screen publishing status might be In production, since you could use production mode back then without Google's approval. For those, I think you can just switch back to Testing status, and you'll be good to go.

Also: this change only affects new authorization requests; if you already authorized Gmvault, and don't need to re-authorize it, then you won't be affected.

[TcT2k]

@gboudreau Thanks for the answer, I've checked in my account and you are correct it was In production (setup a long time ago). I was able to use the Return to Testing button.

[gboudreau]

Of note : I think in Testing, your authorizations are only valid for 7 days, but there is a workaround:

It seems that there is a way to circumvent the 7 days expiration for the refresh token. You have to publish the application and then skip sending any verification details. Just clicking the publish button and creating a new refresh token is enough (sometimes you need to recreate again after 7 days in order for it to work).

(ref)

[DavidBerdik]

Also: this change only affects new authorization requests; if you already authorized Gmvault, and don't need to re-authorize it, then you won't be affected.

So this would only impact new GMvault users that aren't already authenticated? If that is the case, then we'll just need to figure out a way for newcomers to authenticate.

[bleistift2]

Of note : I think in Testing, your authorizations are only valid for 7 days, but there is a workaround:

It seems that there is a way to circumvent the 7 days expiration for the refresh token. You have to publish the application and then skip sending any verification details. Just clicking the publish button and creating a new refresh token is enough (sometimes you need to recreate again after 7 days in order for it to work).

(ref)

In doing so you will again be affected by the deprecated OAuth out-of-band (OOB) flow. At least that's what the email I received from Google said.

So it seems there's either having to renew the token every 7 days or using password instead of oauth?

[DavidBerdik]

So it seems there's either having to renew the token every 7 days or using password instead of oauth?

Using a password is not straightforward either because earlier this month, Google blocked support for using your password to log in to IMAP or SMTP. The only way to use IMAP or SMTP now is to enable 2FA for your account and generate an app password.

[bleistift2]

So it seems there's either having to renew the token every 7 days or using password instead of oauth?

Using a password is not straightforward either because earlier this month, Google blocked support for using your password to log in to IMAP or SMTP. The only way to use IMAP or SMTP now is to enable 2FA for your account and generate an app password.

I could live with an app password. What's the reason that the login with password is referred to as (not recommended) in the documentation?

[DavidBerdik]

What's the reason that the login with password is referred to as (not recommended) in the documentation?

It's probably not recommended because your password is stored in plaintext.

[cheesionz]

In case it helps someone, here are the steps to re-auth using a non-deprecated flow (Loopback for desktop app).

This assumes you've already configured your own OAuth flow for authorisation via the Google API Console.

1. Open the GMVault config located in %userprofile%\.gmvault called _gmvaultdefaults.conf
2. Set _redirecturi to http://127.0.0.1:8123
3. Run the Python webserver code below (this will allow you to receive and copy the verification code).

   
   from http.server import BaseHTTPRequestHandler, HTTPServer
   from urllib.parse import urlparse, parse_qs
   import time

hostName = "localhost" serverPort = 8123

class MyServer(BaseHTTPRequestHandler): def parse_code(self, path): path_parsed = urlparse(path) qs_dict = parse_qs(path_parsed.query) return qs_dict["code"][0]

def do_GET(self):
    self.send_response(200)
    self.send_header("Content-type", "text/html")
    self.end_headers()
    self.wfile.write(bytes("<html><head><title>GMVault OAuth handler</title></head>", "utf-8"))
    self.wfile.write(bytes(f"<p>Verification code is: '{self.parse_code(self.path)}'</p>", "utf-8"))
    self.wfile.write(bytes("<body>", "utf-8"))
    self.wfile.write(bytes("</body></html>", "utf-8"))

if name == "main":
webServer = HTTPServer((hostName, serverPort), MyServer) print(f"Server started http://{hostName}:{serverPort}")

try:
    webServer.serve_forever()
except KeyboardInterrupt:
    pass

webServer.server_close()
print("Server stopped.")

5. Start GMVault and authenticate as before, but instead copy the code from the browser page that should open.

[DavidBerdik]

@cheesionz I want to use this method, but the redirect_uri field keeps changing back to redirect_uri=urn:ietf:wg:oauth:2.0:oob every time I try running it.

Update: I forgot about the conf_version bug. Changing the version from 1.9.1 to 1.9 stopped this behavior from occurring.

[jose-rausell]

Hi folks, this is a elegant solution i found that worked for me, https://wolfnotes.doulos.at/backing-up-gmail-with-gmvault/

Hope it helps.

[dasb00ter]

In case it helps someone, here are the steps to re-auth using a non-deprecated flow (Loopback for desktop app).

This assumes you've already configured your own OAuth flow for authorisation via the Google API Console.

1. Open the GMVault config located in %userprofile%.gmvault called _gmvaultdefaults.conf
2. Set _redirecturi to http://127.0.0.1:8123
3. Run the Python webserver code below (this will allow you to receive and copy the verification code).

from http.server import BaseHTTPRequestHandler, HTTPServer
from urllib.parse import urlparse, parse_qs
import time

hostName = "localhost"
serverPort = 8123

class MyServer(BaseHTTPRequestHandler):
    def parse_code(self, path):
        path_parsed = urlparse(path)
        qs_dict = parse_qs(path_parsed.query)
        return qs_dict["code"][0]

    def do_GET(self):
        self.send_response(200)
        self.send_header("Content-type", "text/html")
        self.end_headers()
        self.wfile.write(bytes("<html><head><title>GMVault OAuth handler</title></head>", "utf-8"))
        self.wfile.write(bytes(f"<p>Verification code is: '{self.parse_code(self.path)}'</p>", "utf-8"))
        self.wfile.write(bytes("<body>", "utf-8"))
        self.wfile.write(bytes("</body></html>", "utf-8"))

if __name__ == "__main__":    
    webServer = HTTPServer((hostName, serverPort), MyServer)
    print(f"Server started http://{hostName}:{serverPort}")

    try:
        webServer.serve_forever()
    except KeyboardInterrupt:
        pass

    webServer.server_close()
    print("Server stopped.")

5. Start GMVault and authenticate as before, but instead copy the code from the browser page that should open.

@cheesionz dont know if your still active in these parts but I am trying to set up a new instance of gmvault using a docker image and get the forbidden out of band error for authorization after setting up the api etc

Where does the python web server code have to be run from. A linux environment? Can you be a little more detailed about running the python webserver. In the end I would like to get it running back in the docker container, so would it be possible to transfer the credentials or default config to the container.

[cheesionz]

@cheesionz dont know if your still active in these parts but I am trying to set up a new instance of gmvault using a docker image and get the forbidden out of band error for authorization after setting up the api etc

Where does the python web server code have to be run from. A linux environment? Can you be a little more detailed about running the python webserver. In the end I would like to get it running back in the docker container, so would it be possible to transfer the credentials or default config to the container.

@dasb00ter the server needs to run wherever you're running GMVault as it uses localhost as the address. Can be any platform that supports Python I believe.

You just need a version of Python installed and then run (assuming Python is on the path):

Python <name of web server file>

That said, without a UI to show the web page you'd need to modify the Python script to print the code to the console.

[dasb00ter]

@cheesionz dont know if your still active in these parts but I am trying to set up a new instance of gmvault using a docker image and get the forbidden out of band error for authorization after setting up the api etc Where does the python web server code have to be run from. A linux environment? Can you be a little more detailed about running the python webserver. In the end I would like to get it running back in the docker container, so would it be possible to transfer the credentials or default config to the container.

@dasb00ter the server needs to run wherever you're running GMVault as it uses localhost as the address. Can be any platform that supports Python I believe.

You just need a version of Python installed and then run (assuming Python is on the path):

Python <name of web server file>

That said, without a UI to show the web page you'd need to modify the Python script to print the code to the console.

Given that could I install a python environment in Linux/Windows authenticate and move the files into the docker environment from the same network

[cheesionz]

Given that could I install a python environment in Linux/Windows authenticate and move the files into the docker environment from the same network

@dasb00ter could work, not sure if there is anything machine specific in the oauth file.

Someone else will have a better idea than me on it, but easy to try!

[dasb00ter]

Anybody know exactly what files would need to be moved? Once Auth is achieved

[kirks]

@dasb00ter I think it would just be the *.oauth2 file in the .gmvault directory of the user.

Here's a node/express script based off the python above that worked for me (different port number):

const express = require('express');

const app = express();
const port = 3000;

app.get('/', (req, res) => {
    console.log(req.query.code);
    res.send(`<!DOCTYPE html><html><body>Code:<pre>${req.query.code}</pre></body></html`);
});

app.listen(port, () => {
    console.log(`Listening on port ${port}`);
});

[dasb00ter]

@dasb00ter I think it would just be the *.oauth2 file in the .gmvault directory of the user.

Here's a node/express script based off the python above that worked for me (different port number):

const express = require('express');

const app = express();
const port = 3000;

app.get('/', (req, res) => {
    console.log(req.query.code);
    res.send(`<!DOCTYPE html><html><body>Code:<pre>${req.query.code}</pre></body></html`);
});

app.listen(port, () => {
    console.log(`Listening on port ${port}`);
});

Thanks are u running from linux. I tried to setup a python environment(2.7) in windows and I couldn't get gmvault to run after pip install. Idk must have been a pathing issue as it seemed to install correctly. I haven't had time to fiddle with it and I am wondering if I should just spin up a linux VM

[kirks]

This was on windows. If you're not familiar with express you can follow this quick start, and just replace the above snippet for the hello world example on page 2: https://expressjs.com/en/starter/installing.html

Not sure why gmvault wouldn't run after a pip install...

[troogyt]

I just installed Gmvault (in fact, I created a new Chocolatey package for v1.9.1 even). I am getting the same issue: cannot authenticate due to the deprecated OOB flow (whatever that means).

Has this been fixed? I have looked at the credentials.py file in here and can see where this redirect_uri is defined, but I don't know what to do to fix it.

[mrankine]

The Python/Node scripts above don't appear to be necessary (for me, at least).

I set redirect_uri=http://127.0.0.1 and conf_version=1.9, ran GMVault and opened the Google authentication link in a browser which then redirects to 127.0.0.1 with a code parameter in the query string. Paste the parameter value into GMVault. It's not necessary to have anything listening on 127.0.0.1.

This can save a bit of time in scenarios where it's not straightforward to run and access a web server, e.g. my Synology NAS.

[neochief]

I confirm that this

In case it helps someone, here are the steps to re-auth using a non-deprecated flow (Loopback for desktop app).

This assumes you've already configured your own OAuth flow for authorisation via the Google API Console.

1. Open the GMVault config located in %userprofile%.gmvault called _gmvaultdefaults.conf
2. Set _redirecturi to http://127.0.0.1:8123
3. Run the Python webserver code below (this will allow you to receive and copy the verification code).

from http.server import BaseHTTPRequestHandler, HTTPServer
from urllib.parse import urlparse, parse_qs
import time

hostName = "localhost"
serverPort = 8123

class MyServer(BaseHTTPRequestHandler):
    def parse_code(self, path):
        path_parsed = urlparse(path)
        qs_dict = parse_qs(path_parsed.query)
        return qs_dict["code"][0]

    def do_GET(self):
        self.send_response(200)
        self.send_header("Content-type", "text/html")
        self.end_headers()
        self.wfile.write(bytes("<html><head><title>GMVault OAuth handler</title></head>", "utf-8"))
        self.wfile.write(bytes(f"<p>Verification code is: '{self.parse_code(self.path)}'</p>", "utf-8"))
        self.wfile.write(bytes("<body>", "utf-8"))
        self.wfile.write(bytes("</body></html>", "utf-8"))

if __name__ == "__main__":    
    webServer = HTTPServer((hostName, serverPort), MyServer)
    print(f"Server started http://{hostName}:{serverPort}")

    try:
        webServer.serve_forever()
    except KeyboardInterrupt:
        pass

    webServer.server_close()
    print("Server stopped.")

5. Start GMVault and authenticate as before, but instead copy the code from the browser page that should open.

@cheesionz I want to use this method, but the redirect_uri field keeps changing back to redirect_uri=urn:ietf:wg:oauth:2.0:oob every time I try running it.

Update: I forgot about the conf_version bug. Changing the version from 1.9.1 to 1.9 stopped this behavior from occurring.

I confirm that this workaround still works in Apr 2024.