How to manage users on the backend when using Auth0 lock?

Question

I am creating an interface with React and backend with Node. I would like to manage user information using Auth0 Lock - sending a JWT with every API request.

What if I need to do one of the following?

• Save blog post with author id

The unique identifier Auth0 has a value of user_id , which is not an integer and therefore cannot be used as an identifier / key. How can I handle this in server side user repository?

• Ask the user table to save the "profile" or other similar information.

I read the JWT for each API request, determine if this user exists, and then create a new user if this is not the case, or associate it with an existing user if that happens. Is a user database validated for each API request?

I am not sure how to handle the common thread using the JWT and Auth0 based APIs.

Edit:

My thoughts after some research and reflection: Auth0's unique user ID is provided by them as user_id . The problem here is that it is not an integer. Therefore, it should not be used as a key for the users table in the database.

It seems that you should not check the user database for each query, but this may not be true. One idea would be to call a backend at the initial login, if the account does not exist, create it, if the account really exists, go to it. Then just trust the Auth0 JWT (if it checks for a backend) for every next request after the user has logged into the interface.

From several descriptions of this process that I have seen on the Internet, it looks like I described this as a normal way. But there are situations when it does not make sense. What if the user should be blocked? They can still access the server functions with their active JWT before it expires.

So, if for checking each of the API requests it is required to check / verify the authenticity of the user repository, how to link the identifier of the string Auth0, user_id , with the identifier of an integer in the data store to execute the requests? I am using the SQL option.

Answer 1

How to identify users

You do not know what database technology you are using, but in general you should be able to use regular strings as identifiers / keys. You note that you are using the SQL version, which may be the source of the problem; you should probably use a more specific fixed-length text data type.

user_id is the result of combining the user_id identifier provider identifier with the user identifier inside this provider, so we can argue that reaching the final maximum length is a bit more complicated. However, you can choose an arbitrary value, for example, something like 640 characters should be enough for everyone.

You can also identify your users by email; this works if each authentication provider used by your application requires users to provide their email, and you also do not intend to support different accounts with the same email address.

The ultimate alternative is for you to assign each user their own unique identifier, which is better suited to how you intend to use it. You can achieve this by setting the Auth0 rule to update the user metadata using this new attribute, and then request this attribute as it is included in the generated token when authenticating the user using domains .

Depending on the approach, you don’t need a simple search table matching one form of identifier with your internal one or in case of updating user metadata using your internal identifier you can completely skip this search table and just the value coming from the JWT.

How to handle new users

As you already mentioned, you can make sure in each API request that if this is the first request issued by a new user, then you create your own view of the application profile before processing the request.

An alternative to this would be to initiate the creation of this application profile from Auth0 when you find that registering the user for the first time, and then in the API always assumes that the profile exists.

Both approaches are valid; I would go with one that would leave you with a simpler implementation and still fit your requirements.

How to handle banned users

If you need to support the ability to immediately ban a user and not allow any other API request, you always need to have some kind of request in each API request to find out if the user has been blocked or not. This greatly increases complexity, so consider that you can endure a solution in which the token expires shorter and banned users can still call your API in this short amount of time.