-
Notifications
You must be signed in to change notification settings - Fork 312
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
service account authentication fails after 1.33.0 release #804
Comments
Thanks for the report! @arithmetic1728 Could you take a look? I think |
Hi, If you're experiencing this issue, please use the prior release |
Thank you for the update! We already had reverted the upgrade, will wait for the next release and the fix. |
We also investigated the issue on our side. In our case, changing the |
thanks, that's good to know. I would have expected the token to be signed, so that it fails when these details are changed, that's why I didn't try to change it. Since there is no rush upgrading the package, we'll just wait for the fix and release |
I can reproduce the error only when I set the "subject" filed for domain-wide delegation. Can anyone confirm if domain-wide delegation is used when you see the error? |
Yep, in our case the service account has domain wide delegation activated |
Revert is under way in #808, we'll take the change again once b/194191737 is resolved. |
just tested the revert with 1.33.1, and it works (which I assumed seeing the code, but still :) ) Thank you for the quick fix! |
Environment details
google-auth
version: 1.33.0Error description
With the update of google-auth to 1.33.0 we saw an error in our environments.
In our case we use a service-account to access google calendars in our org.
In our service-account key we find
"token_uri": "https://accounts.google.com/o/oauth2/token"
, while the library setsaud
to behttps://oauth2.googleapis.com/token
via a constant. This was changed with the 1.33.0 release in 0e26409.When I monkey-patch the constant to have the same value as the token-uri in our accounts, everything works again.
Is this a bug? Or a configuration issue on our side?
I'm happy to provide detailed steps to reproduce this if needed. Also I'm not sure about the relation to #464.
The text was updated successfully, but these errors were encountered: