chore: use original API request context for auth token requests

[ctreatma]

#844 updated the Config object to create a new auth client every time a new Fabric API client was created for SDK resources. If we stuck with this pattern, we would have to duplicate that behavior for every Equinix API client except for Metal. In addition, this pattern means that the provider will make a separate auth token request per resource rather than reusing valid tokens across all resources that use the same provider (and therefore auth) config.

This reverts the auth client change by adopting a custom HTTP transport and OAuth token source that enables passing the original request context for an API request to the auth token client. As a result, we no longer need to use equinix/oauth2-go.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 96.77419% with 1 line in your changes missing coverage. Please review.

Project coverage is 48.19%. Comparing base (f3d9263) to head (fd0f6c5).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
internal/config/config.go	96.77%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##             main     #847       +/-   ##
===========================================
+ Coverage   27.94%   48.19%   +20.24%     
===========================================
  Files         240      240               
  Lines       31715    31712        -3     
===========================================
+ Hits         8864    15283     +6419     
+ Misses      22696    15733     -6963     
- Partials      155      696      +541     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[thogarty]

Awesome, @ctreatma !

I'm still working through the lower level details but your implementation looks solid from a decent high level understanding.

I'm curious if this removes the API Request/Response from the log output though with a different round tripper. If it does then I'll add it back in with a follow up after looking into it.

[thogarty]

Awesome, @ctreatma !

I'm still working through the lower level details but your implementation looks solid from a decent high level understanding.

I'm curious if this removes the API Request/Response from the log output though with a different round tripper. If it does then I'll add it back in with a follow up after looking into it.

Answered my own question. It doesn't because we still wrap this in logging.NewTransport which handles that for us with an additional wrapper. Good to go 👍

[ctreatma]

@displague also interested to get your take on this one.

[Copilot]

Copilot reviewed 4 out of 5 changed files in this pull request and generated 1 comment.

Files not reviewed (1)

• go.mod: Language not supported

Comments suppressed due to low confidence (2)

internal/authtoken/oauth2.go:90

• The error message 'oauth2: server response missing access token' could be more descriptive. Consider including additional context about the server response.

return nil, fmt.Errorf("oauth2: server response missing access token")

internal/config/config.go:83

• The new behavior introduced in 'newAuthClient' function is not covered by tests. Ensure that this function is properly tested.

c.authClient = c.newAuthClient()

[thogarty]

@ctreatma + @displague , what are your thoughts on this one?

We've got an open Goalie ticket for auth related issues on fabric_service_profile data source. My theory is that they're hitting a rate limiting issue trying to get so many auth tokens for each call.

This should fix that issue.

[ctreatma]

I think we should be a bit more certain that the requests are being rate-limited for the customer in question before merging/releasing a change to auth logic for all customers. While this should be safe for everyone, it's nonetheless a core change and comes with some risk.

In terms of pure mechanics, releasing this will require review/merge/release of the corresponding SDK changes, and I don't recall how hacked-in those changes are.

SDK draft PR used for this feature: equinix/equinix-sdk-go#102

[ctreatma]

@displague @thogarty The SDK has been updated with accesstokenv1 support and the corresponding context-aware TokenSource, so this PR is ready for final review.

The Fabric test workflow was recently changed such that this PR did not trigger the workflow; rather than address that here I ran the test workflow manually against this branch: https://github.com/equinix/terraform-provider-equinix/actions/runs/15980969812

[displague]

In the test failures, I see evidence that #912 is needed (to add the missing shell script used for processing test output) and I see this equinix_fabric_route_aggregation sweep failed (@thogarty):

2025/06/30 18:45:55 [DEBUG*** Sweeping Route Aggregations
2025/06/30 18:45:55 [DEBUG*** POST https://uatapi.equinix.com/fabric/v4/routeAggregations/search
2025/06/30 18:45:55 [DEBUG*** Completed Sweeper (equinix_fabric_route_aggregation) in region (all) in 408.432994ms
2025/06/30 18:45:55 [ERROR*** Error running Sweeper (equinix_fabric_route_aggregation) in region (all): error getting streams list for sweeping fabric route aggregations: 400 Bad Request Code: EQ-3044002, Message: Invalid argument value passed., Details: Invalid argument value passed., AdditionalInfo: [***Property: /values, Invalid argument value passed.***

Aside from several other Fabric 400s due to resources not being available to the user, I see no signs that this optimization to use a generated SDK for auth token processing negatively affected authentication/authorization.

[github-actions]

This PR is included in version 3.11.1 🎉