Suggestion: Factor out leaky abstractions of oauth2_client

[jollytoad]

kv_oauth sits atop oauth2_client, but exposes much of the inner workings of oauth2_client, this I feel is a leaky abstraction in that it leaves kv_oauth at risk from major oauth2_client API changes, and prevents (however unlikely) future consideration of alternatives, or even direct inclusion of just the essential parts of that lib should it ever become unmaintained.

One way to address this is to pass config rather than client as addressed by #174, but it's been discussed that the config adopts OAuth2ClientConfig directly.

There are three issues I have with this interface:

1. It's exported from a module that also contains the OAuth2Client class, placing a dependency burden on anything that wants to reference this type
2. It exposes a number of options that could be deemed unnecessary (at this time at least) for a highly level lib like kv_oauth, namely: defaults.requestOptions & defaults.stateValidator
3. If we discard those, this leaves us with defaults.scope which feels unnecessarily nested

My proposal is for kv_oauth to expose it own config type that better fits it use case and developer experience, exposing only options that are necessary for kv_oauth, and to protect it from potential future changes, abandonment, or even the consideration of alternatives to the underlying oauth2_client API.

I feel that this is something that could be neatly addressed now whilst in beta stage, as it'll be a lot harder to plug the leaks later.

[jollytoad]

To be fair, point 1 is probably something to be raised with the oauth2_client project.

[jollytoad]

Ok raised cmd-johnson/deno-oauth2-client#38 for point 1, but I still uphold concern regarding the other points even if this change is accepted in the oauth2_client lib.

[jollytoad]

A dedicated kv_oauth config type protects against adoption of new features too, such as OpenID Connect support (#194) ... the API introduces a new interface for that config... https://github.com/cmd-johnson/deno-oauth2-client/blob/feature/oidc/src/oidc/oidc_client.ts#L6

This would difficult if OAuth2ClientConfig was the type we pass around, as OIDCClientConfig can't just be dropped in place due to certain props being required.

A dedicated kv_oauth config type would be able to seamlessly add in the additional optional props for OIDC though, and the internal client creation could choose use the OIDCClient, if and only if the required additional props had been supplied.

[iuioiua]

There are three issues I have with this interface:

1. It's exported from a module that also contains the OAuth2Client class, placing a dependency burden on anything that wants to reference this type
2. It exposes a number of options that could be deemed unnecessary (at this time at least) for a highly level lib like kv_oauth, namely: defaults.requestOptions & defaults.stateValidator
3. If we discard those, this leaves us with defaults.scope which feels unnecessarily nested

I agree that the 3 points made are indeed sub-optimal. However, I wouldn't say they are issues in this module. The difference between OAuth2ClientConfig and a possible custom interface would be marginal. This difference doesn't sufficiently justify having a custom interface. OAuth2ClientConfig works fine.

This would difficult if OAuth2ClientConfig was the type we pass around, as OIDCClientConfig can't just be dropped in place due to certain props being required.

We can use config: OAuth2ClientConfig | OIDCClientConfig and perform checks where needed 🙂

[iuioiua]

I've created cmd-johnson/deno-oauth2-client#41 to suggest making the OAuth2ClientConfig interface flat.