♻ Implement PKCE auth using `react-oidc` library

[tristan-orourke]

Description

In our current authentication strategy, the client makes a call to our API, which communicates with an OAuth 2.0 identity provider, exchanging a client secret for access tokens, and then passes tokens back to the client using url query variables.

We want to replace this with an OAuth authentication flow using PKCE, where the client can request tokens directly from the identity provider. To make this refactor easier, we want to use a frontend library to handle the auth flow in the background.

@patcon previously researched auth module options in #2572, and recommended https://github.com/AxaGuilDEv/react-oidc. We have chosen this library because it has good active support, and unlike other options, it protects against XSRF attacks by storing tokens in a service worker instead of localStorage or a cookie.

The library suggest that the service worker can inject tokens directly into fetch requests, which may make it unnecessary to use auth-exchange in urql. That probably requires testing.

Acceptance Criteria

• [ ] Authentication is handled through the https://github.com/AxaGuilDEv/react-oidc library
• [ ] If possible, simplify our urql client provider by avoiding use of auth-exchange
• [ ] User experience of logging in and out is unchanged.
• [ ] We can continue to use React Router to specify that certain routes require being authenticated with certain roles
• [ ] Refreshing access tokens continues to happen silently in the background
• [ ] Using the app in multiple tabs does not cause any issues (as in #4523)
• [ ] Necessary communications with Sign-In Canada to keep auth working

[petertgiles]

Currently blocked on localhost issues.

• Requests to mockauth go to different hostnames between the api (inside the docker bridge network) and the browser (outside of docker). This fails out the key validation. This might be solvable with mockauth configuration.
• Requests for the configuration data from the .well-known endpoints now come from the browser and are subject to CORS protections. It should be possible to add CORS headers to mockauth but I haven't figured it out yet. SIC should be able to add the headers, too.
• Chrome rejects CORS requests from localhost always.
• I tried a browser extension that hacks on the CORS headers but the SIC captcha is rejecting it.

[brindasasi]

Currently blocked on localhost issues.

• Requests to mockauth go to different hostnames between the api (inside the docker bridge network) and the browser (outside of docker). This fails out the key validation. This might be solvable with mockauth configuration.
• Requests for the configuration data from the .well-known endpoints now come from the browser and are subject to CORS protections. It should be possible to add CORS headers to mockauth but I haven't figured it out yet. SIC should be able to add the headers, too.
• Chrome rejects CORS requests from localhost always.
• I tried a browser extension that hacks on the CORS headers but the SIC captcha is rejecting it.

@petertgiles are these blockers still valid to implement this issue?

[petertgiles]

To get around these issues we would need to stop using the localhost domain on our workstations. As we didn't have much luck with IMTD setting up a loopback domain for us we decided as a team that we would be willing to edit our workstation hosts files. That should unblock this issue.

[tristan-orourke]

Icebox because we might actually get to SSR before we get to this 😆