User creation architecture

[jamieparkinson]

The core goal of the membership epic is for users to be able to provision themselves in Sierra. We have a few options for how this is to be achieved technically:

1. Naïve solution: add a user creation endpoint to the identity API (TypeScript, this repo in /packages/apps/identity-api) which calls the Sierra API to create a user. This is appealingly simple, but it has a number of disadvantages:

   • It circumvents Auth0 security mechanisms and conveniences.
   • How do we log the user in post signup?
   • By bypassing Auth0, we couple ourselves (more) to Sierra, making it harder to consider alternative identity sources.
   • We have to maintain a signup experience entirely separately to the login experience, which is hosted within Auth0 (universal login).

2. New universal login + database script: this is the minimal change within our current architecture; we would use the registration form as provided by Auth0 and we would implement the Create user custom database script to provision users in Sierra.

   There is one key disadvantage here: the registration form only supports username, email and password fields. In order to populate other mandatory fields (namely, first and last names), we would have to take a progressive profiling approach whereby a custom action would direct the user to input further fields immediately after signup.

   It's worth noting that we will likely have to take a progressive profiling approach in later phases of the membership project (for collecting user addresses etc).

3. Classic universal login + database script: as above, but reverting to the classic universal login experience, which is much more customisable than the new universal login despite some disadvantages.

   This would require migrating our existing signup and password reset pages to classic universal login, too, but on the other hand it would enable us to customise those too.

[jamieparkinson]

Bits and pieces:

• Additional signup fields in Classic universal login with Lock: https://auth0.com/docs/libraries/lock/lock-configuration#additionalsignupfields-array-
• The Next.js Auth0 SDK does not support non-universal login: https://github.com/auth0/nextjs-auth0/issues/141

Slack conversations I've found (interesting context):

• https://wellcome.slack.com/archives/C0198JT4GTG/p1619170523187400
• https://wellcome.slack.com/archives/C0198JT4GTG/p1615474324049800?thread_ts=1615474105.049300&cid=C0198JT4GTG

[melanierogan]

I've done a quick spike on option 2, where we continue to work with universal login.

It looks like we can redirect to another form at the point of signing up with universal login. I’ve tried this is a sandbox developer account and used an online sample of a consent form (in lieu of a full sign up page with consent form). It looks like, despite universal login meaning we need to get a user’s email and password first, we can still redirect to a sign up form (as per the original user flows) as part of the membership process. Note: the verify your email address email is sent as soon as you fill out email and password and hit submit).

Mel, i’m tired, explain that again: We can continue to use universal login for membership work by just adding one step to the start of the user flow here, email and password first.

(To see video of the sample universal sign up process from sandbox account click here)

[melanierogan]

I have tried to update the user flow to allow for this extra step, you can check the miro board here I will now try to go through tickets we have to add these considerations where relevant. We will probably need a few more tickets relating to this work too.

[melanierogan]

We decided to keep this ticket 'in progress' so that it is a reminder of our 3 possible approaches, even though we've gone with option 2. It'll also remind me to update Carla when she's back.