Replace oidc-client-js with something future-proof

[kuosandys]

Description

The OIDC client package we use is no longer being actively maintained, and has now been officially archived. While we probably won't need to rely on new OIDC features being implemented, this also means that the dependencies this package requires also won't be actively updated, including for security-related patches.

As there doesn't seem to be a stable and direct replacement for the package, we can consider a few options:

1. Maintain our own fork of oidc-client-js to keep the package dependencies updated ourselves
2. Replace with a similar package - AppAuth-js looks to be an alternative other projects are turning to, though it also has less built-in features. This would require us to implement and test the features we need ourselves.

TODO

• Maintain our own fork of oidc-client-js #887
• Keep an eye out for other promising alternatives(oidc-client-ts is a fork of the original oidc-client-js repo and ported to TS)
• Replace with oidc-client-ts
• archive our fork ofoidc-client-js

[ghost]

Actions points:

1. Investigation
2. Estimation

[kuosandys]

Investigation

The current package we use provides a nice higher-level API to manage sign in/out, claims, and tokens for a user (documentation here we use the UserManager class). We then expose this in our application via a React context provider. This is also currently the only client-side JS library that is OpenID Connect certified.

There are many other wrapper libraries for this package that are also in search of a suitable future replacement (see the issues mentioned here for some examples), though none of these projects appear to have made a decision yet.

There is currently a fork of the original package oidc-client-ts that seeks to be a TS replacement, but in my opinion, it is still not long-lived or adopted enough yet to guarantee that it will be maintained in the long-run.

Another OIDC library for JS applications, as mentioned in the issue description above, is AppAuth-JS. However, this is not a direct replacement for oidc-client-js, as it is more "bare-bones", providing only support for manual interactions to perform token exchanges. Choosing to use this library would mean implementing a wrapper ourselves to manage OIDC flows, tokens, etc. A simple example of this can be found here. If we choose this option, we also need to ensure that the features we now implement ourselves are fully tested.

An alternative solution would be to maintain our own fork of oidc-client-js. We will likely not require new features of OIDC any time soon, and would just be keeping the dependencies up to date to avoid security issues. The repository is public and can be scanned on Snyk. Currently, there is a vulnerability with the crypto-js dependency.

Estimation

Effort estimation depends on how we choose to move forward:

• If we choose to maintain our own branch of oidc-client-js in the short-run, while waiting for other alternatives to emerge and mature, the effort is quite low.
• If we choose to adopt AppAuth-JS, there is some amount of implementation and testing to be done, especially to ensure that user authentication is not disrupted. In my opinion, the effort here is at least medium.

[ghost]

Thanks @kuosandys for the info, I'll plan for this task soon, just after we know the teams preference on the options. But personally I prefer option 1 at the moment then when we have some time we do option 2.

[kuosandys]

I talked about this with @gusevda today and we both agreed that the effort of replacing oidc-client-js with AppAuth-JS outweighs the benefits it would bring us. We won't be taking advantage of any new features, and there's also the added risk of introducing new errors with the new code we'd add.

The best course of action currently is to fork the oidc-client-js repo and keep the dependencies up to date ourselves. We can then continue to keep an eye out for other alternatives better suited to our needs.

[ghost]

Cool, thanks @kuosandys , let us enumerate the tasks related to this decision. Do you think we should have some kind of monitoring or reminder to check on the dependencies to tell us that new versions are available, or we are already alerted ?

[kuosandys]

Cool, thanks @kuosandys , let us enumerate the tasks related to this decision. Do you think we should have some kind of monitoring or reminder to check on the dependencies to tell us that new versions are available, or we are already alerted ?

As a start, I've enabled dependabot alerts and updates for security vulnerabilities.

[marians]

Do you think we can close this issue, now that we decided for our own fork? Or is it needed as a reminder?

[kuosandys]

Do you think we can close this issue, now that we decided for our own fork? Or is it needed as a reminder?

I still think we should keep an eye out for viable alternatives, but whether we need to keep an issue open to track that is a good question. One drawback of closing the issue is the potential that we forget about this over time.

What action do we usually take for these type of issues that don't require immediate action, but serve more as a reminder?

[kuosandys]

Released with happa v1.57.3