Appt 1413: Authentication refactor to the front end

[pata9]

Description

As part of a spike to add the ability to refresh a cookie in MYA, we looked at how much of a refactor it would be to get MYA authentication going direct to the OIDC server instead of going via the API. This is because with the introduction of refresh tokens we're more than likely going to need to create the concept of an auth session in MYA. With this it would make sense that all of these concerns live within the UI. This PR demonstrates the changes that would be required.

The main change is in configuration -
type AuthProvider = { NAME: string; HOST_URL: string; IS_DIRECT: boolean; OFFLINE_ACCESS_ENABLED: boolean; TOKEN_URL: string; CLIENT_ID: string; CODE_CHALLENGE: string; CLIENT_SECRET: string; REQUIRES_STATE_FOR_AUTHORIZE: boolean; };

• NAME is the same as provider name at the moment (currently nhs-mail or okta)
• HOST_URL is the URL for the initial redirect to the OIDC server.
• TOKEN_URL is the URL for any token requests (initial code request and/or refresh token). This would be called in set-cookie
• IS_DIRECT may not be needed, but I wanted to avoid using feature toggles for this. Dictates the behaviour of the config, should I go direct to the OIDC server or go via the API (existing flow)
• OFFLINE_ACCESS_ENABLED is similar to the IS_DIRECT but dictates if we should request offline_access scope. offline_access scope is the only thing needed to enable refresh_tokens

We will need to update the redirect URLs if we go ahead with this refactor. We'll also need to enable offline access for OKTA and NHS Mail as part of enabling refresh tokens.

• Redirect URL should be set to a single value of https://{MYA_ENV_DOMAIN}/manage-your-appointments/auth instead of one for each provider. OIDC typically works off the route being correct and not the absolute URL. In the interest of making our lives easier we should move to this format.
• Offline_Access enables refresh tokens and must be enable before we roll out any refresh logic

Useful links

• Duendes docs on clients and offline access
• NextJS docs on sessions

Fixes # (issue)

Checklist:

• My work is behind a feature toggle (if appropriate)
• If my work is behind a feature toggle, I've added a full suite of tests for both the ON and OFF state
• The ticket number is in the Pull Request title, with format "APPT-XXX: My Title Here"
• I have ran npm tsc / lint (in the future these will be ran automatically)
• My code generates no new .NET warnings (in the future these will be treated as errors)
• If I've added a new Function, it is disabled in all but one of the terraform groups (e.g. http_functions)
• If I've added a new Function, it has both unit and integration tests. Any request body validators have unit tests also
• If I've made UI changes, I've added appropriate Playwright and Jest tests
• If I've added/updated an end-point, I've added the appropriate annotations and tested the Swagger documentation reflects the change

[pata9]

Enabling -

[pata9]

This route is only designed for a direct provider, should error out if it's not

[pata9]

When this was in the API we would log the fact the User had logged in, do we need to keep this and add it somewhere in here?

[pata9]

When offline access is enabled this is when we should create a session and enable refreshing the token

[pata9]

I'm sure there's a better way to add these variables :)

[pata9]

The mock oidc server throws an SSL error NODE_TLS_REJECT_UNAUTHORIZED added to get round it