Repository navigation
Fix Google Cloud connection IdP extra request parameters being ignored - #76161
Merged
o-nikolas merged 5 commits intoNov 5, 2026
Merged
Conversation
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.
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.
Contributor
Author
|
@shahar1 - Could you please review and merge this PR if everything is good. |
1 task done
o-nikolas
approved these changes
Nov 4, 2026
1 task done
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]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The "IdP Extra Request Parameters" field of the Google Cloud connection never reached the
identity provider, for two independent reasons:
provider.yamlstore the value under theidp_extra_parametersextra, but
GoogleBaseHookreadidp_extra_params, so a value entered in the UI wasignored.
_CredentialProviderreceivedidp_extra_params_dictbut never passed it toClientCredentialsGrantFlowTokenSupplier, so the parameters were dropped even when thehook did read them.
The hook now reads
idp_extra_parametersand falls back toidp_extra_params, the onlykey 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 thevalues.
Was generative AI tooling used to co-author this PR?
Generated-by: Code Puppy following the guidelines