Skip to content

Fix Google Cloud connection IdP extra request parameters being ignored - #76161

Merged
o-nikolas merged 5 commits into
apache:mainfrom
pavansai1997:fix-google-idp-extra-parameters
Nov 5, 2026
Merged

o-nikolas merged 5 commits into
apache:mainfrom
pavansai1997:fix-google-idp-extra-parameters

Conversation

@pavansai1997

@pavansai1997 pavansai1997 commented Oct 31, 2026 •

Copy link
Copy Markdown
Contributor

The "IdP Extra Request Parameters" field of the Google Cloud connection never reached the
identity provider, for two independent reasons:

  • The connection form and provider.yaml store the value under the idp_extra_parameters
    extra, but GoogleBaseHook read idp_extra_params, so a value entered in the UI was
    ignored.
  • _CredentialProvider received idp_extra_params_dict but never passed it to
    ClientCredentialsGrantFlowTokenSupplier, so the parameters were dropped even when the
    hook did read them.

The hook now reads idp_extra_parameters and falls back to idp_extra_params, the only
key that was read until now, so connections whose extras were written by hand keep working.

Making the parameters reach the supplier exposed a third issue: the token cache key only
included the parameter names, so two connections that differ only in a parameter value
(for example audience) would have shared a cached token. The cache key now includes the
values.


Was generative AI tooling used to co-author this PR?
  • Yes — Code Puppy

Generated-by: Code Puppy following the guidelines

The "IdP Extra Request Parameters" connection field never reached the
identity provider. The form and provider.yaml store it as
idp_extra_parameters while GoogleBaseHook read idp_extra_params, and
_CredentialProvider never passed the parsed parameters on to
ClientCredentialsGrantFlowTokenSupplier.

Read idp_extra_parameters, falling back to idp_extra_params for
connections whose extras were written by hand, and pass the parameters to
the token supplier. Include parameter values in the token cache key so
connections that differ only in a parameter value, such as audience, do
not share a cached token.
@pavansai1997
pavansai1997 requested a review from shahar1 as a code owner October 31, 2026 18:03
@boring-cyborg boring-cyborg Bot added area:providers provider:google Google (including GCP) related issues labels Oct 31, 2026
Joining the cache key components with plain concatenation, commas and
equals signs let different credentials produce the same key, for example
{"audience": "foo,scope=bar"} and {"audience": "foo", "scope": "bar"}, or
client ID "ab" with secret "c" and client ID "a" with secret "bc". Such
connections would share a cached token.
@pavansai1997

Copy link
Copy Markdown
Contributor Author

@shahar1 - Could you please review and merge this PR if everything is good.

@o-nikolas
o-nikolas merged commit a1be2c1 into apache:main Nov 5, 2026
80 checks passed
bingqin2 added a commit to bingqin2/airflow that referenced this pull request Nov 7, 2026
Since apache#76161 the IdP extra request parameters of a Google Cloud connection reach the token
request. Extras that would replace grant_type, client_id or client_secret, or collide with the
supplier's oidc_issuer_url argument, now fail with a clear ValueError; the field must hold a JSON
object; and values under sensitive key names are masked in task logs.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:providers provider:google Google (including GCP) related issues

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants