使用Auth0 Lock时如何管理后端用户？

Question

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

What if I need to do one of the following things?

• Store a blog post with an author ID

The Auth0 unique identifier is user_id , which is not an integer and therefore cannot be used as an ID/key. How would I handle this on a server-side user store?

• Have a users table to store a "profile about" or other similar information

Do I read the JWT on each API request, determine if that user exists, and then create a new user if it doesn't, or relate it to a pre-existing user if it does. Is it performant to check the user database on every single API request?

I am unsure how to handle general flow with JWT-based API and Auth0.

Edit:

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

It seems as if you shouldn't check the user database on each request, but this may be incorrect. One idea would be to callback to the backend on initial login, if the account doesn't exist, create it, if the account does exist, move on. Then just trust the Auth0 JWT (if it verifies on the backend) on each following request after the user has logged in on the frontend.

From the very few descriptions of this process I have seen online, it seems like the way I described was the normal way. But there are some situations where it doesn't make sense. What if a user was to be banned? They could still access the server functionality with their active JWT until it expires due to time.

So, if it is normal/performant to check the user store on each API request, how do I relate Auth0's string id, user_id , to an integer ID in the datastore to do queries? I am using a SQL variant.

Answer 1

How to identify users

You're not explicit about which database technology you use, but in general you should be able to use regular strings as identifiers/keys. You do mention that you're using SQL variant so that may be the source of the issue; you should probably use a more specific text-based data type with a fixed length enough.

The user_id is the result of concatenating the Auth0 identity provider identifier with the user identifier within that provider so we could argue that reaching a definitive max length is a little trickier. However, you can decide on arbitrary value, for example, something like 640 character ought to be enough for anyone.

You can also identify your users by email; this works if every authentication provider being used by your application requires users to provide their email and you also don't intend to support different accounts with the same email address.

A final alternative is for you to assign each user your own unique identifier that is better suited for how you intend to use it. You can achieve this by having an Auth0 rule update your user metadata with this new attribute and then request this attribute to be included in the generated token upon user authentication by the means of scopes .

Depending on the approach you would neither need a simple lookup table mapping one form of identifier to your internal one or in the case you update the user metadata with your internal identifier you could skip that lookup table entirely and just the value coming from the JWT.

How to handle first-time users

Like you mentioned, you could at each API request make sure that if this is the first request issued by a new user then you create your notion of application profile before processing the request.

The alternative to this would be triggering this application profile creation from within Auth0 when you detect that the user signup for the first time and then on the API always assume the profile exists.

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

How to handle users being banned

If you do need to support the ability to immediately ban a user and don't allow any other request to the API then you'll always have to have some kind of query at each API request to see if the user was banned or not. This increases the complexity significantly so do consider that you can tolerate a solution where the lifetime of a token is shorter and banned users may still call your API within that short time frame.