[2.42.0] Bug with impersonated account token refresh

After updating from 2.41.1 to 2.42.0 I get this issue:

  File "C:\...\.venv\Lib\site-packages\google\auth\transport\requests.py", line 535, in request
    self.credentials.before_request(auth_request, method, url, request_headers)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\...\.venv\Lib\site-packages\google\auth\credentials.py", line 228, in before_request
    self._blocking_refresh(request)
    ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^
  File "C:\...\.venv\Lib\site-packages\google\auth\credentials.py", line 191, in _blocking_refresh
    self.refresh(request)
    ~~~~~~~~~~~~^^^^^^^^^
  File "C:\...\.venv\Lib\site-packages\google\auth\credentials.py", line 365, in refresh
    self._refresh_token(request)
    ~~~~~~~~~~~~~~~~~~~^^^^^^^^^
  File "C:\...\.venv\Lib\site-packages\google\auth\impersonated_credentials.py", line 289, in _refresh_token
    self._source_credentials._refresh_token(request)
TypeError: 'str' object is not callable

It seems this commit changed the refresh logic of impersonated account credentials at exactly this line: 36ecb1d#diff-9fb6744f480c88b7964f845792d2d930c9a7048caee2ba4931dc2c899c623cb6L289

Reverting back to 2.41.1 fixes it.

Python: 3.13.9

Also seeing this please fix ASAP

Yes! It took me forever to debug this issue because we updated google-auth as part of a much large upgrade, but in the end it came down to the move from 2.41.1 to 2.42.0, and it's still broken with 2.42.1 from earlier today.

Minimum reproducible environment (in development) for me has:

a single config like this:

% gcloud config list
[auth]
impersonate_service_account = service-account@myproject.iam.gserviceaccount.com
[core]
account = gonzalo@company.com
disable_usage_reporting = False
project = myproject

which is authenticated via

gcloud auth application-default login

And a pyproject.toml with a single unpinned dependency, google-cloud-bigquery managed by uv. With that environment uv solves to 3.38.0 for bigquery and 2.42.1 for google-auth. In that scenario, this test command:

uv run python -c "from google.cloud import bigquery; list(ds.dataset_id for ds in bigquery.Client().list_datasets())"

returns the str not callable error:

  File "/Users/gonzalo/Git/goog6/.venv/lib/python3.11/site-packages/google/auth/impersonated_credentials.py", line 289, in _refresh_token
    self._source_credentials._refresh_token(request)
TypeError: 'str' object is not callable

If I add a constraint on google_auth <2.42, it gets solved to 2.41.1 and the same test command runs and exits without errors.

For completeness'sake, here's the pyproject.toml from the example that returns the str not callable error:

[project]
name = "goog6"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.11"
dependencies = [
    "google-auth>=2.42",
    "google-cloud-bigquery==3.38.0",
]

I ran it with Python 3.11.13

We're facing a similar problem too!

problem is is with either of these two PRs:

https://github.com/googleapis/google-auth-library-python/pull/1820/files
https://github.com/googleapis/google-auth-library-python/pull/1809/files

This is a blocker for us

Confirming that pinning google-auth==2.41.1 resolved the issue for me (needed it for google-cloud-texttospeech==2.31.0 service). Checked on Python 3.13.5.

also confirming this has been broken for us since the 2.42.0 release and pinning to 2.41.1 resolves the issue

+1, quite blocking with any services which needs to refresh the credentials.

+1

We have the same issue as well. Please fix it at the earliest.

problem is is with either of these two PRs:
https://github.com/googleapis/google-auth-library-python/pull/1809/files

Yes, It looks like in #1809 the Credentials subclasses in google.auth where updated to change _refresh_token -> _refresh_token_val and change refresh_token from an attribute to a method. The corresponding change in google.oath2 were not implemented and the test has that attribute mocked so i guess was missed in testing.

Can confirm that it's an issue in python 3.12.11 as well as 3.13.x. Similarly, downgrading to 2.41.1 resolves the issue

fix: rename internal refresh token attribute to _refresh_token_val an…

Still an issue with google-auth 2.43.0 breaks impersonated credentials, causing TypeError: 'str' object is not callable. Downgrading to 2.41.1 for now.

venv\Lib\site-packages\google\auth\impersonated_credentials.py", line 289, in _refresh_token
self._source_credentials._refresh_token(request)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^
TypeError: 'str' object is not callable

How is it that this bug in a core auth library has existed for over a month with no response? Is impersonation really that unpopular?

@daniel-sanche

This is blocking us as well and it seems like a big issue overall with a simple fix. I hate to do this, but I'm tagging a couple of people that could be maintainers (as determined by their contribution ranking) to see if we can get this fix merged:

Well, I think there is a mix up with google.auth.impersonated_credentials.Credentials and google.oauth2.credentials.Credentials classes. I think the fix should be just this.

if isinstance(self._source_credentials, credentials.CredentialsWithTrustBoundary):
    self._source_credentials._refresh_token(request)
else:
    self._source_credentials.refresh(request)

I think that should work, but before #1809 those interfaces were the same. I think the fix should be to align the interfaces once again (#1875). Looking at the tests, that does seem to be the intended behaviour, but the mocking means it was missed.

I m more concerned that even though a PR #1875 was created there is no review on it from past 2 weeks.

Are googlers left for the remainder of the year? Why is this not fixed yet?

It seems there might be some movement? #1884

(sadly the PR didn't ref this issue)

Hi all,

I've been following this thread. Coming from an enterprise environment where we rely heavily on ImpersonatedCredentials via Vault (short-lived source credentials), I suspect the issue might be in how the refresh method handles the underlying source_credentials expiry state before attempting the IAMCredentials API call.

I am planning to investigate this over the weekend.

My goal is to:

Create a minimal reproduction script that forces a token expiry on the source credential to see if it propagates the error correctly.
If confirmed, submit a PR to ensure the source is refreshed upstream before the impersonation call.

If anyone has a reproduction script that is already working/failing consistently, please share it to speed this up.

This was fixed in 2.44 it seems

fixed by #1884

Navigation Menu

Repository navigation

[2.42.0] Bug with impersonated account token refresh #1850

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[2.42.0] Bug with impersonated account token refresh #1850

Description

Activity

jmesterh commented on Oct 30, 2025

capitantoto commented on Oct 30, 2025

GeeekyBoy commented on Oct 31, 2025

Sylver11 commented on Oct 31, 2025

drewgillson commented on Oct 31, 2025

neurowelt commented on Nov 10, 2025

agentbrain commented on Nov 11, 2025

camilleAmaury commented on Nov 12, 2025

wwangsa commented on Nov 12, 2025

kranthibandaru commented on Nov 12, 2025

mikeedjones commented on Nov 20, 2025

spkgyk commented on Nov 20, 2025

mathewswoolies commented on Dec 1, 2025

jmesterh commented on Dec 1, 2025

sebastian-correa commented on Dec 2, 2025

iostreamdoth commented on Dec 4, 2025

mikeedjones commented on Dec 4, 2025

iostreamdoth commented on Dec 4, 2025

onur-lh commented on Dec 5, 2025

mfriedy commented on Dec 9, 2025

SuryaTejaSusarla commented on Dec 30, 2025

mfriedy commented on Dec 30, 2025

mikeedjones commented on Jan 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions