Allow pluggable OkHttp client

The auth0 client internally uses OkHttp as its http client. Quickly skimming the codebase, it looks like the API is designed to abstract/hide this from the SDK consumer.

The problem

However, this makes it difficult to re-use an existing OkHttp client (for example, a singleton OkHttp bean in a spring boot project). Sharing a single okhttp client is the recommended approach according to the OkHttp docs: https://square.github.io/okhttp/4.x/okhttp/okhttp3/-ok-http-client/#okhttpclients-should-be-shared

Ideal Solution

Ideally, the constructors would accept a pre-existing OkHttp client. For ex:

public AuthAPI(..., OkHttpClient client) {
  ...
}

It could still initialize the client with its own configuration with newBuilder(): https://square.github.io/okhttp/4.x/okhttp/okhttp3/-ok-http-client/#customize-your-client-with-newbuilder

Alternatives and current work-arounds

There are no current work-arounds apart from forking the SDK to add this constructor.

I’m happy to take up the implementation of this if it’s something the maintainers are open to merging!

[jimmyjames]

While I do think allowing for a pluggable HTTP client is something this library should support, I don’t think exposing the OkHttp dependency directly is the best solution. It couples this library more/too closely with a specific Http client, which could lead to issues with versioning/configuration (see #324 for an example of how upgrading to OkHttp v4 negatively impacted users using Spring’s dependency management), along with leaking too much dependency details as discussed above.

I think a more optimal solution is to provide a generic networking client interface for which we can provide a default implementation, yet also allow clients to provide an implementation providing their own networking client if desired. That’s something that we are considering for the next major version release.

If there are additional networking configurations required in v1, HttpOptions could be modified within the v1 stream to support that, for which we can address via issues/PRs.

[gsdatta]

@jimmyjames no specific client configurations – I was just looking to reuse a OkHttpClient which I would pass in to the SDK instead of having the SDK instantiate one on its own (since there are ramifications to that).