CLI OAuth workflow never finishes with custom URI in redirect_url

[soumith]

Describe the bug

In the duck CLI, take a simple workflow such as duck -l googledrive:/.
The CLI opens a browser, which does the OAuth workflow.
Once authenticated, the expectation is that you either have the OAuth redirect the CLI or some code shows on browser that you can paste back into CLI.
However, the OAuth redirect_url is set to open the CyberDuck app, and does not respect that the duck CLI originated the OAuth workflow.

To Reproduce
Steps to reproduce the behavior:

1. Go to command-line
2. Run duck -l googledrive:/
3. Try to finish authentication workflow

Expected behavior
You expect the workflow to finish.
Either the OAuth takes you back to CLI and CLI finishes auth, or you get instructions on how to manually finish the workflow.

Desktop (please complete the following information):

• macOS 12.4
• [Also checked] Linux Ubuntu 20.04

Logs with --debug :
foo.log

[dkocher]

This was missed in #13366.

[dkocher]

Not sure how we should implement this, as manual copy & paste of authentication code ¹ is deprecated .

Footnotes

1. Important: The manual copy/paste option, also referred to as an out of band (OOB) redirect method, is DEPRECATED and will be removed in October 2022. Review the OOB migration guide for instructions on how to migrate to a secure alternative. https://developers.google.com/identity/protocols/oauth2/native-app#manual-copypaste ↩

[soumith]

from the migration guide, the most matching option seems to be a loopback IP address -- so cyberduck temporarily listens on some localhost+port and that is given as the redirect_uri

https://developers.google.com/identity/protocols/oauth2/native-app#redirect-uri_loopback

[dkocher]

Relates to #13476.

[dkocher]

from the migration guide, the most matching option seems to be a loopback IP address -- so cyberduck temporarily listens on some localhost+port and that is given as the redirect_uri

https://developers.google.com/identity/protocols/oauth2/native-app#redirect-uri_loopback

We don't currently have an implementation using a listener on the loopback address as it is prone to man in the middle attacks. it is still feasible for desktop apps according to the documentation ¹

…but will continue to be supported on desktop apps.

Footnotes

1. https://developers.google.com/identity/protocols/oauth2/resources/loopback-migration ↩