Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Google change will break GAM authentication #1483

Closed
jay0lee opened this issue Feb 18, 2022 · 2 comments
Closed

Google change will break GAM authentication #1483

jay0lee opened this issue Feb 18, 2022 · 2 comments
Assignees
Labels
bug security Security Issue

Comments

@jay0lee
Copy link
Member

jay0lee commented Feb 18, 2022

The Google changes at:

https://developers.googleblog.com/2022/02/making-oauth-flows-safer.html

are going to break GAM's default OAuth flow which is OOB. Desktop localhost auth is NOT deprecated and is the flow we should move to using by default. A few things:

  • on/after Feb 28, 2022 new GAM installs and projects will break when trying to use OOB. Existing projects, including the project GAM itself uses to create projects will break for OOB login flows in (Sept 2022?) about 6 months.
  • it's possible to tell existing GAM versions today to use localhost. You just need to create a file called oauthbrowser.txt in the GAM folder.
  • the current localhost implementation does NOT support headless machines like Google Cloud Shell where no browser is present on the client. It won't be possible to authenticate on those machines The only workaround for those machines and current GAM versions will be to create the oauth2.txt credentials elsewhere and move the file(s) onto the headless machine.
  • I'm working on an update to GAM that will default to localhost and starting a web server / browser to pass the auth token. At the same time and for headless installations, GAM will allow you to copy the auth URL, perform the auth on a "headed" machine which has a browser and then copy the auth code back to the headless machine. There are going to be a few challenges with such a flow:
  1. GAM used to use the localhost flow as the default. We stopped doing so because more and more users were running GAM on a headless Linux server or such AND because we found even on "headed" Windows laptops, it wasn't uncommon for a firewall on the device to block the localhost connection. These will continue to be a problem for us.
  2. The current python implementation of localhost flow in run_local_server() starts the web server and (tries) to start a web browser then it waits forever for a HTTP request from the web browser. No browser on the device means we're stuck.

I'm currently working on a replacement to both OOB run_console() and localhost run_local_server() flows. This flow will attempt to start the web server and browser but will also prompt for the auth code to be entered directly into the GAM console. That way user can copy the auth URL to another "headed" machine, complete the auth there and paste the resulting auth code back into GAM console. However, in such a scenario we'll still need a web server running on the "headed" client to handle the redirect back to localhost Google will make and present the user with the auth code to be copied back to GAM. We can do two things here:

  • have a GAM command like gam oauth justlisten that simply starts a web server on localhost and handles the browser redirect at the end of the auth flow. It can then present the auth code to the user in the browser and GAM client for an easy copy/paste back to the headed server. This command should not do ANYTHING special with OAuth, client secrets, etc since it won't know any of the project details being setup on the headless server.
  • above solution may be challenging for some users to run. Corp policy may prevent running GAM binaries on the local machine or it may be a Chromebook without Crostini where GAM can't run. In those cases, we can direct the user that at the end of the auth flow they will be redirected to a localhost URL and loading that page will fail. They should copy that full URL and paste it back into GAM. GAM can then parse the redirect URL and extract the auth code from it. Not pretty but it removes the requirement from running GAM on the browser machine.

@taers232c FYI

Fun times. :-/

@jay0lee jay0lee added bug security Security Issue labels Feb 18, 2022
@jay0lee jay0lee self-assigned this Feb 18, 2022
@jay0lee
Copy link
Member Author

jay0lee commented Feb 22, 2022

Still needs to be done:

  • catch bad auth codes / urls and reprompt user rather than giving up
  • catch potential errors
  • provide better messaging to users on auth process and what they can do when localhost does not respond in browser (that's expected for headless)
  • write a standalone command that will only start the web server and respond with code in browser to be copied to headless device. This should not depend on ANY local config files.

@jay0lee
Copy link
Member Author

jay0lee commented Mar 14, 2022

These updates were released with 6.17. Closing this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug security Security Issue
Projects
None yet
Development

No branches or pull requests

1 participant