Skip to content

feat(go/adbc/driver/bigquery): add external-account (WIF) auth#134

Open
ragesh-g wants to merge 1 commit into
mainfrom
ragesh/bq-support-wif
Open

feat(go/adbc/driver/bigquery): add external-account (WIF) auth#134
ragesh-g wants to merge 1 commit into
mainfrom
ragesh/bq-support-wif

Conversation

@ragesh-g
Copy link
Copy Markdown

@ragesh-g ragesh-g commented Jun 3, 2026

Summary

This adds Workload Identity Federation (WIF) as an authentication option for the BigQuery driver. With WIF, a workload authenticates through an external identity provider (Microsoft Entra, in the dbt setup) and Google grants BigQuery access based on that.

How it works

When a profile uses this method, the driver:

  1. asks the identity provider (e.g. Entra) for a token, by sending the sign-in request the user put in their profile;
  2. trades that token with Google for a short-lived Google access token;
  3. optionally "borrows" a service account's identity (impersonation), if the profile points at one;

then uses the resulting token to run BigQuery jobs.

It reads four new settings from the profile: the workload pool/provider path, the provider's token URL, the request body to send it, and an optional service-account impersonation URL.

Testing

  • Go unit tests.
image
  • Manual dbt run against BigQuery via Entra WIF, driven through dbt-labs/fs#10486.

Dependency

Paired with dbt-labs/fs#10486 (the dbt side that sets these options).

@ragesh-g ragesh-g force-pushed the ragesh/bq-support-wif branch 7 times, most recently from 76ffbc3 to c5f5dbf Compare June 3, 2026 11:42
@ragesh-g ragesh-g force-pushed the ragesh/bq-support-wif branch from c5f5dbf to a39cd55 Compare June 3, 2026 11:43
@ragesh-g ragesh-g marked this pull request as ready for review June 4, 2026 14:11
req.Header.Set("Accept", "application/json")
req.Header.Set("Content-Type", "application/x-www-form-urlencoded")

resp, err := idpHTTPClient.Do(req)
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I generally agree the network call should be at this layer. I think we should do exponential backoff with jitter here. Make constants at top of the file. start at 500ms, tiny bit of jitter to prevent collisions. This keeps it at 15ish seconds worst case for a total failure, which is well within the 30s timeout already on the HTTP client. Don't expose the retries upstream

}

var tokenResponse bigQueryTokenResponse
if err := json.Unmarshal(body, &tokenResponse); err != nil {
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

anyway we can map the error to something more human readable? Ask claude, I -think- there are some cases we'd like to be more sophisticated in catching the errors since this might show up in fs as something like "cannot unmarshal into json" and users would have no idea what's going on

Copy link
Copy Markdown

@VersusFacit VersusFacit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Request for retry logic, but this is pretty much good to go

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants