Passwordless | Reset password with passcodes handle case for non-existent users

[coldlink]

What does this change?

In #2852 we implemented passcodes for reset password for some "ACTIVE" users. Namely the ones with both the "password" and "email" authenticator, and users with just the "email" authenticator.

In #2889 we implemented passcode for reset password for the remaining active users, i.e the ones with only the "password" authenticator.

And in #2902 we implemented passcode for reset password for existing users in the non-ACTIVE state.

There is one more group of users that could go through the reset password process, and these are users who currently don't have a Guardian account.

To prevent username enumeration, the behaviour in the UI has to be the same as for all the other user states. Specifically we have to show the /reset-password/email-sent page, with a passcode input box.

Since these are non-existent users, we cannot send an email to them for obvious reasons. So in this PR we've taken the same approach that is used for the existing legacy reset password pages, i.e we just show the email sent page and in our additional information box we include our noAccountInfo messaging. This messaging says that if you don't receive an email within two minutes, then you likely don't have an account, and includes a link to create one.

The cypress test I've added in this PR covers this behaviour.

---

We also modify the way we set the EncryptedState cookie in this PR. This is because this cookie can get quite large, and in some cases could exceed the maximum size of what was allowed in the Cookie header (only noticed on DEV and CODE).

So we remove undefined keys and values, to reduce the size slightly.

The bigger change was finding out that the Okta IDX API stateHandle is 817 characters in length! But it turns out we don't need to persist the entire stateHandle in the Encrypted State.
In fact all we need is the first 46 characters (before the ~). This is actually the same bit that is required for the stateToken parameter in the /login/token/redirect endpoint used after authentication, see for more context

gateway/src/server/lib/okta/idx/shared/idxFetch.ts

Line 128 in 34311cd

`/login/token/redirect?stateToken=${response.stateHandle.split('~')[0]}`;

and

gateway/src/server/lib/okta/openid-connect.ts

Line 39 in 34311cd

stateToken?: string; // state handle from Okta IDX /introspect response but only everything before the first tilde (`stateHandle.split('~')[0]`), used to redirect user to login redirect endpoint to set global session (`/login/token/redirect?stateToken=${stateToken}`)

for more context.
The IDX API seems to work with only that bit (tested with Hoppscotch). So we don't actually need to persist the other 774 characters, and having the cypress tests pass provide us with confidence that this change works.

Tested

• CODE

Future options

While this PR doesn't send an email to users, we could work with Data Privacy and other teams to figure out if we can send users an email, for example letting users know that they don't currently have an account, or potentially even creating an account for users if they go through the reset password flow.

[github-actions]

Deploy build 10040 of identity:identity-gateway to CODE

All deployment options

• Deploy build 10040 of identity:identity-gateway to CODE
• Deploy parts of build 10040 to CODE by previewing it first
• What's on CODE right now?

---

From guardian/actions-riff-raff.

[akinsola-guardian]

Thanks for taking us through this. LGTM