OAuth Support in Terraform

[squat]

Hi, reading through the docs I see that there is some support for manually configuring OAuth authentication in Go SDKs (https://www.speakeasyapi.dev/docs/customize-sdks/authentication#oauth), however, it looks like this doesn't apply at all to Go code generated for a Terraform provider. Is that right?

When generating a Terraform provider for an API that uses OAuth, the name of the security scheme is always treated as a string in the provider's schema, rather than some kind of object as would be required for OAuth. For example, an OpenAPI spec with the following security schem:

components:
  securitySchemes:
    oauth2:
      type: oauth2
      description: This API uses OAuth 2 with client credentials flow.
      flows:
        clientCredentials:
          tokenUrl: /oauth2/token
          scopes:
            fullAccess: full access to the API
          refreshUrl: /oauth2/refresh

results in a provider type that looks like:

// FooProviderModel describes the provider data model.
type FooProviderModel struct {
	ServerURL types.String `tfsdk:"server_url"`
	Oauth2    types.String `tfsdk:"oauth2"`
}

Is there any workaround currently? If not, what plans are there to support OAuth in Terraform (if any).

Thanks!

[ThomasRooney]

That's right -- we don't have an obvious hook to add in oAuth support.

We have had several users add in oAuth support through monkey patching. I.e. the underlying Go SDK supports adding in a security source callback (e.g. a function, called on every API Call, that returns security.Security; and hence can retrieve and intelligently cache an oAuth token). To use this we have a .genignore file which can be configured with provider.go, followed by the logic to configure oAuth retrieval being manually augmented into the provider.go.

We've been considering other methods to make this easier ; but haven't got a great plan right now. Options we've considered are:

• Trying to generically generate an oAuth2 compliant API call, caching/cache invalidation scheme, and hence generate the security source automatically. Unfortunately the amount of custom/variant oAuth2 server implementations scare us; so we keep putting this off. This is our ideal solution though
• Trying to build in a more obvious hook file for oAuth that can be monkey patched to configure SDK instantiation, to avoid a monkey patched provider missing out on new resources/data sources.
• Trying to build in a mechanism of monkey patching a file directly, to allow a subset of it to be automatically generated.