Skip to main content

Sign Up Flow

Context​

We are moving our login and sign up flows from Hybris to Auth0. As part of this change, we need to introduce a two step registration so we are able to capture additional metadata about our customers such as compliance, marketing consent, terms and conditions and so on. This process is called progessive profiling. We have had to move to this model as you are currently not able to add custom fields to the New Universal Login. Once this feature becomes available we will be able to remove this extra step.

Decision​

Flow​

  1. The user initiates sign up from Hybris. Auth0's SDK redirects the user to the Auth0 Authorization Server (/athorize endpoint).

  2. Your Auth0 Authorization Server redirects the user to the sign up form.

  3. The user then enters their email and password and hits submit. At this point the user is created in Auth0. Because we are then auto logging in our users they are moved into the login flow. Note that actions in this flow are synchronous, which means they execute as part of a triggers process and will prevent the rest of the Auth0 pipeline from running until the Action is complete.

    1. The first function to fire as part of this action is onExecutePostLogin. In this function we must:
      1. Check if the logins_count is equal to 1. This means it is the users first login and we must action the progressive profiling.
      2. Create a password using a uid generator. This will be used to tie a user between Auth0 and Hybris.
      3. Create the user in Hybris. See Step 4.
      4. Create the user in Exponea. See Step 5.
      5. Set the password in the app metadata of the user. This was created in b. used to tie users between Hybris and Auth0.
      6. Once they have been created in Hybris we must get the user from Hybris and set their access token as a custom claim on the ID Token. This access token is used for auto login as well as requesting API endpoints in our Next.js applications.
      7. We then redirect the user to the progressive profiling application. We must generate an token that we pass to the profilling application which contains the continue_uri and a session_token we must decode. Auth0 automatically adds a state query param. More details about the token and state can be found in the Redirect with Actions section.

  4. Create the user in Hybris. This user will contain the uid and password created in the previous step.

  5. Create the user in Exponea. This won't contain any consents or profilling information.

  6. Redirect the user to the progressive profilling application.

    1. Here we must first verify the JWT token using the same secret as Auth0.
    2. Once this is verified we should do some tests on the token to make sure it has not been tampered with. More details can be found in the Redirect with Actions section.
    3. Save profilling data in Auth0. See Step 7.
    4. Finally we have to redirect back to Auth0 using the continue_uri from the token and including the state from Auth0.

  7. Users profilling data is set against the users metadata using the Management API.

  8. Authentication is resumed by redirecting the user to the /continue endpoint, including the state parameter you received in the URL.

  9. The user is then updated in exponea using the metadata set against the user via the Management API. This information will be available on the event.user.app_metadata object.

  10. Finally the user is returned to the Hybris and the auto-login process takes over.

Redirect with Actions​

You can use post-login Actions to redirect users before an authentication transaction is complete. This lets you implement custom authentication flows that require additional user interaction beyond the standard login form.

How it works​

At a high level, a Redirect Action works in the following manner:

  1. An Action issues a redirect to a URL. In our case the progressive profiling application.
  2. The Actions pipeline is suspended after that Action completes its execution.
  3. The user is redirect to the URL along with a state parameter and a jwt token (session_token).
  4. When the external flow has concluded, the external site redirects the user to a /continue endpoint along with the state parameter.
  5. The Actions pipeline is resumed on the same Action that invoked the redirect.

Start a redirect​

Call the api.redirect.encodeToken and api.redirect.sendUserTo() functions as follows:

/**
* @param {Event} event - Details about the user and the context in which they are logging in.
* @param {PostLoginAPI} api - Interface whose methods can be used to change the behavior of the login.
*/
exports.onExecutePostLogin = async (event, api) => {
  const token = api.redirect.encodeToken({
      secret: event.secrets.MY_REDIRECT_SECRET,
      expiresInSeconds: 60, 
      payload: {
        // Custom claims to be added to the token
        continue_uri: `https://${YOUR_AUTH0_DOMAIN}/continue`
      },
  });
  
  api.redirect.sendUserTo("http://auth.rapha.cc/profile", {
     query: { session_token: token }
  });
};

After the Action has finished executing, Auth0 redirects the user to the URL specified in the api.redirect.sendUserTo() function. Auth0 also passes a state parameter in that URL. For example:

http://auth.rapha.cc/profile?state=abc123

Your redirect URL will need to extract the state parameter and send it back to Auth0 to resume the authentication transaction. State is an opaque value, used to prevent Cross-Site Request Forgery (CSRF) attacks.

Resume the Authentication Flow​

After the redirect, resume authentication by redirecting the user to the /continue endpoint and include the state parameter you received in the URL. If you do not send the original state back to the /continue endpoint, Auth0 will lose the context of the login transaction and the user will not be able to log in due to an invalid_request error.

When a user has been redirected to the /continue endpoint, the Actions pipeline will resume on the same Action that invoked the redirect by calling the onContinuePostLogin function. For redirects to work properly, you must have a function with the following signature in the same Action that invoked the redirect:

/**
* @param {Event} event - Details about the user and the context in which they are logging in.
* @param {PostLoginAPI} api - Interface whose methods can be used to change the behavior of the login.
*/

exports.onContinuePostLogin = async (event, api) => {
}

This is the point where we would update Exponea with what data we have captured from the progressive profilling application. Just to note the PPA uses the management api to save user data against the users metadata.

Ensure the token has not been tampered with​

The PPA should verify that this token has not been tampered with during transit. To accomplish this, the application should ensure the token’s signature is valid and, if applicable, that the session in the PPA belongs to the same Auth0 user provided in the sub claim of the token.

Use app metadata where possible​

As mentioned above the PPA should use the Management API to store custom information as application metadata on the Auth0 user profile. When the Auth0 Action flow is resumed, this information will be available on the event.user.app_metadata object. This approach avoids passing sensitive information to Auth0 on the front channel.

Consequences and limitations​

  1. The PPA is an undesirable solution to not being able to add custom fields to the New Universal Login. This is however a temporary feature until that becomes available.
  2. Actions are goverened by a strict list of limitations. Most notable are the size and execution time. Please refer to the actions documentation or for a complete list of limtations, please visit auth0.

Resources​