You don't need a user table

Identify user​

We recommend using user.sub to identify a user since we guarantee every user has a unique and non-null id property.

Also, username primary_email and primary_phone are unique properties. But they may be empty. Remember to handle null properly if you want to use these properties to identify a user.

Why no user table​

When preparing to take Auth as an identity solution, you may think about approaches to organizing user information and user-related stuff.

Traditionally, developers will create a user table in a SQL database containing the profile and other user-related information, then create a many-to-one relation in other tables, a user column pointing to the user table. For other identity providers, take Google as an example. Create a column named google_id to achieve "sign in with Google" linking. Now, for Auth, you may want to create a column auth_id, but it is not a good way since Auth is more than a social provider, it is a solution that can take charge of all user-related stuff.

With the help of Auth, you don't need a user table.

Here is a common practice (with Auth):

Forget the user table, store user info in Auth

1. Create user_id column in other tables, save Auth's user.sub, refer to the previous chapter Identify User.

2. Call Auth's Management API for CRUD: create and update a user, get user detail, list users...

3. Save any additional user information to custom fields.

By doing this, Auth is now playing the "user table" role.

Let's say that you have an "Online Store" app using Auth as the identity service, and you want two features:

1. Store user preference data in the cloud.

2. Access control for different groups of users.

With the help of custom_fields, we can quickly implement this, and the data object will be like:

{
 "appearenceMode": "DarkMode",
 "role": "customer"
}

CAUTION

You cannot do "join" or other complex queries on Auth's user storage. In this circumstance, you should use a cache layer or your own user table.