Auth0 database store VS custom database

Hi,

I’m having trouble determining what is the best solution for me.

The reason I started looking into Auth0 is I wanted a way to store my user data without having to worry about writing all the scripts for encrypting the user data such as passwords. I wanted to use Auth0’s database store… but I’m beginning to think that it can’t provide me the user data that I need to store.

In the database, I need my users to have a username field, password field, and a second password. This second password you can think of as an access code (It can be the same for all users). This password will be sent to another API that will need it in order to handle sending messages for users.

My initial thought is that I could set a global password where I can call the API from the post-registration web hook to insert this password into their database… but then, I’m not sure how I can retreive this password from my mobile side code? My other issue is that each user MUST have a unique username that they cannot change. This username will be inserted into the API’s database.

My other issue is that I noticed Social Logins do not create a username field. =( A username field would be required because I need a field that will ALWAYS stay the same so that I could grab that data from Auth0’s database and send it to the other API’s database. And then when I need the information I still need to know what username was stored in the other API’s database for the user.

Anyone have any suggestions?

If I went with a custom database on Auth0, what are the disadvantages?? Would this still prevent me from offering social login… because I still need a unique username?? Is there a way to auto-generate a username field for ALL login types? Would I still have to figure out encryption if I used a custom database???

In the database, I need my users to
have a username field, password field,
and a second password. This second
password you can think of as an access
code (It can be the same for all
users). This password will be sent to
another API that will need it in order
to handle sending messages for users.

Auth0 Database connections support usernames - this can be easily toggled from the Auth0 dashboard:

Your second password requirement can be handled by app_metadata. App_metadata is stored under the user profile, however cannot be modified by the user. As you mentioned, you can add app_metadata to a user using the Post User Registration hook. You can then retrieve this in your application with a call to the /userinfo or /tokeninfo endpoints.

Note: If you are using your second password as a way to securing your API calls, you should take a look at our API Authorization docs to see how you can handle this more securely.

A username field would be required
because I need a field that will
ALWAYS stay the same so that I could
grab that data from Auth0’s database
and send it to the other API’s
database. And then when I need the
information I still need to know what
username was stored in the other API’s
database for the user.

As mentioned above, you can store a custom username field in app_metadata. As a side note, it would be easier and more efficient (less API calls to Auth0 to retrieve userinfo) to use the user_id as the identifier in your database, rather than username.

I thought that if I added a password field to the metadata then the password is no longer secure… encrypted?

Do you know if social logins also have the user_id field?? If I have this set to merge accounts (for same email address), which user_id would it keep??

I’m also running into a 500 error when I try to call my REST service from a web hook. I need this REST to be called every time a user registers an account. Any ideas?

You can Encrypt sensitive data in the user profile in a Rule.

All users will have a user_id, including social logins. Linking accounts will maintain the user_id of the primary user, however the user_id of the secondary user will still be available in the user.identities array. This is outlined here: https://auth0.com/docs/link-accounts