WebAPI compatibility

[pzuraq]

We would like to use this library in our Cloudflare workers app so that we can store our user's session info alongside the client apps that they are logged into, without exposing that session info directly to the browser. Looking through the code and the dependencies this library has, it seems like it would pretty straightforward to make it work with both the workers environment and Node. jose already works in browsers, and there are minimal usages of other node APIs, which could be converted to web equivalents.

Is there interest in supporting Cloudflare workers/non-Node environments? If so, we could donate some time to build it out.

[panva]

Looking through the code and the dependencies this library has, it seems like it would pretty straightforward to make it work with both the workers environment.

I don't share this opinion. The code base as-is is not likely to be portable to WebAPI-compatible environment.

It may be the case that i'll do stripped down version of the library as a universal one that the node one will then depend on. No capacity for taking that on at the moment tho.

[pzuraq]

What would be the barrier there? If we're talking converting to ES modules proper, I agree it would be a pretty significant rewrite. I'm halfway through a PR which would use native web APIs in place of Node APIs while still using commonjs syntax, however, which should still be compatible with most modern build tooling.

Is the concern that some of the Node API usage cannot be ported?

[panva]

I'm halfway through a PR

Impressive, but very premature. I'm certain I don't want to dip into the WebAPI space with this package. As I wrote above, maybe a barebones universal client separate of it but this will remain a Node openid-client. There's a scope to what I can sustain.

[pzuraq]

Fair enough, we'll operate on a fork for the time being then. Thanks for the excellent work, the library is very solid and very easy to use, have tried a few others and despite being web compatible, this one is so much better that we have no hesitation to take the time to do the work to convert 😄

If you want I can PR the changes once I have it working just for reference, but if there's truly no interest we'll just operate on the fork!

[panva]

I'll be checking out your fork, no need to open a PR.

[pzuraq]

Alright, I pushed the changes here if you are interested at all: https://github.com/pzuraq/node-openid-client/tree/make-web-compatible

The current implementation just does typeof !== 'undefined' checks to determine which environment it's in, and then uses the corresponding APIs. This is a bit hacky, and requires user to manually ignore require('crypto') (e.g. set it to external in ESBuild), but works pretty well all things considered. If this were to move forward, I would want to:

1. Add support for for mTLS. mTLS will only ever be available in Node I believe, since we can't control the HTTP agent using plain fetch, but it should be possible in Node using a custom agent with node-fetch.

2. Add/finish support for dpop. This requires some things with private keys, and since we aren't using that I decided not to figure out how to translate it.

3. Update the build so that we could output two builds when publishing, one for cloudflare/browser environments and the other for Node. I think I would go with a global define based system, e.g.:

   if (BROWSER) {
     // browser impl
   } else {
     // node impl
   }
   

   At build time, we would transform BROWSER to true or false, and then use dead code elimination to remove the other branch. This would allow us to ship both builds without requiring browser users to mark crypto as external.