docker-credential-gcr
docker-credential-gcr copied to clipboard
GoogleCloudPlatform
OOB OAuth just got turned off
login still uses OOB and see https://developers.google.com/identity/protocols/oauth2/resources/oob-migration
It seems like this only affects docker-credential-gcr gcr-login invocations that set -no-browser?
And there's no other alternative for desktop applications (if I'm reading this right) besides using the browser flow.
Would you suggest we just drop this flag? Or is there something else we could do here?
We're going through the process of getting this oauth client as onboarded as 'official' on the google side. Does gcr-login not work at all now?
(Internal only) screenshot of the challenge screen:
https://screenshot.googleplex.com/38kwQYgeKABsACx
Any update on this? Will it be fixed? Or does anybody have an alternative approach how to get this functionality?
We are working on getting the OAuth flow approved. Can you please provide exactly what commands you are running that have changed? We want to make sure we understand all the client interactions that we need to check.
We are using docker-credential-gcr configure-docker and docker-credential-gcr gcr-login to authenticate developers with their personal accounts on our iot edge devices. This is part of our development and support workflow.
Just to make sure we're aligned - currently docker-credential-gcr configure-docker works as it used to, and docker-credential-gcr gcr-login also works in my testing.
But docker-credential-gcr gcr-login -no-browser is broken.
If this isn't the same as you're seeing, please let us know.
Yes, docker-credential-gcr configure-docker works as it used to.
docker-credential-gcr gcr-login does not work any more with and without -no-browser option.
docker-credential-gcr gcr-login doesn't any more work if it is unable to launch the browser. In this case it works the same as -no-browser.
We are working on fixing the oauth flow.
There are some potential workarounds, they involve using gcloud to do authentication. I know that's not an option for every situation.
If gcloud is installed, docker-credential-gcr will fall back to using gcloud for authentication if you don't do gcr-login.
Alternatively you can use gcloud directly for docker authentication - see 'gcloud auth configure-docker'
Would some variant of this work perhaps?
https://stackoverflow.com/questions/71364188/how-to-authorize-a-curl-script-to-google-oauth-after-oauth-out-of-band-oob-flo/72981466#72981466
Would some variant of this work perhaps?
https://stackoverflow.com/questions/71364188/how-to-authorize-a-curl-script-to-google-oauth-after-oauth-out-of-band-oob-flo/72981466#72981466
I did a quick test of it and ran into the same problem...
Yes we are working on this. To have the oauth flow trusted we have to go through a security review, and we're working through that right now.
That's good, thanks!
Do you have a possible timescale for this? Days? Weeks? Months?
Thanks!
Hi, after reviewing this some more and based on discussions with the security reviewers, it turns out I didn't completely understand the change. The OOB flow that uses the copy/paste mechanism is being deprecated for all clients regardless of whether they are 1st or 3rd party apps:
https://developers.google.com/identity/protocols/oauth2/resources/oob-migration
The only thing we can fix is that the browser-based oauth flow will stop showing a warning when you go through that process. We unfortunately don't have any alternative for this library for browserless login.
The first alternative I can see is to use gcloud. While the oob flow is also being removed from gcloud, it does support a --no-browser flag which allows login provided you can run a command on another machine that has both gcloud and a browser.
https://cloud.google.com/sdk/docs/authorizing#run_gcloud_auth_login
Alternatively, you can log in as a service account with gcloud using a json key.
Once you are logged in with gcloud then docker-credential-gcr will fallback to gcloud to get an auth token.
Apologies for the ambiguity, I know it's frustrating when auth flows stop working. We're beholden to the oauth team on this.
Not good at all. This attempt to improve security will end up with lots of people using solutions that have worst security properties, like the service json key, or even worst. I can't think on an alternative that has acceptable usability and good security properties. Even if I want to write custom code to generate and refresh json keys, there is till the problem of the root of trust for the rotation. This whole thing is counter-productive and punishes people who adopted gcr/gar.
