You can customize the user signup form with more fields in addition to email and password when using Lock or the Auth0 API.
There are many factors to consider before you choose Lock vs. Custom UI. For example, using Lock, you can redirect to another page to capture data or use progressive profiling. When using the Auth0 API, you can capture custom fields and store them in a database. There are certain limitations to the customization that should be considered when choosing the method that best suits your purpose. Some typical customizations include adding a username and verifying password strength.
Universal Login recommended
Auth0 offers a Universal Login option that you can use instead of designing your own custom login or signup pages, or using those that are embedded in any of the Auth0 libraries. If you want to offer signup and login options, and you only need to customize the application name, logo and background color, then Universal Login might be an easier option to implement.
Lock supports custom fields signup.
additionalSignUpFields option will only work with database signups. For signups using social identity providers, collecting these fields in the same manner is not possible with Lock, but there are two other options to allow social IDP signups with Lock while still collecting additional custom fields.
Redirect to another page
One way to use social provider signups with Lock and collect custom fields is to use redirect rules to redirect the user to another page where you ask for extra information, and then redirect back to finish the authentication transaction.
Another way to collect custom field data when signing users up with social providers is via progressive profiling whereby you can slowly build up user profile data over time. You collect the bare minimum details upon signup, but when a user later interacts with your app, you collect a small amount of data (perhaps one question) each time until their profile is complete. This allows you to collect the desired information but with less friction, since the goal of using a social IDP for signup is making it more effortless and streamlined for the user.
Using the API
Create a signup form to capture custom fields
name is a user profile attribute and
color is a custom field.
There is currently no way to validate user-supplied custom fields when signing up. Validation must be done from an Auth0 Rule at login, or with custom, server-side logic in your application.
Send the form data
Send a POST request to the /dbconnections/signup endpoint in Auth0.
You will need to send:
passwordof the user being signed up
The name of the database
connectionto store your user's data
Any user profile attribute you want to update for the user, which can include
Any custom fields as part of
Custom fields limitations
When your users sign up, the custom fields are sent as part of
user_metadata. The limitations of this field are:
user_metadatamust contain no more than 10 fields
user_metadata.fieldmust be a string
user_metadata.field.value.lengthmust be fewer than 500 characters
user_metadata.field.lengthmust be fewer than 100 characters
The current size limit for
user_metadatais 16 MB
After a successful login, Auth0 will redirect the user to your configured callback URL with a JWT (
id_token) in the query string.
Your server will then need to call APIv2 to add the necessary custom fields to the user's profile.
Add username to the signup form
One common signup customization is to add a username to the signup.
To enable this feature, turn on the Requires Username setting on the Connections > Database section of the dashboard under the Settings tab for the connection you wish to edit.
username field in your custom form, and add the
username to your request body.
Optional: Verify password strength
Password policies for database connections can be configured in the dashboard. For more information, see: Password Strength in Auth0 Database Connections.
If required for implementation of custom signup forms, the configured password policies, along with other connection information, can be retrieved from the Management v2 API. The result can be parsed client-side, and will contain information about the current password policy (or policies) configured in the dashboard for that connection.