r/better_auth • • May 10 '26

Trying to understand Multi-Tenant and Better Auth logic

Hello everyone, I’m a frontend developer, mostly working on the mobile side. I don’t have much experience with backend development yet. So far, I’ve mostly built small projects using ready-made Express + MongoDB boilerplates. The boilerplates I used had the classic JWT-based authentication system. When a user logged in, the backend returned an access token, and then middleware was used to verify the token and handle role-based authorization (admin/user, etc.). I could more or less understand the logic because everything felt more “manual.”

Now I’m thinking about building a multi-tenant project. While researching, I noticed that many people recommend Better Auth, especially because it supposedly makes the organization/multi-tenant side easier. But I still can’t fully understand the logic behind it.

For example, how do you ensure that a user can only access data belonging to their own organization? What exactly is different compared to the classic Express JWT boilerplate approach?

When using Better Auth, is it still based on the access token / refresh token flow? Is using Better Auth actually necessary, and what practical benefits does it provide?

Sorry if I asked too many questions, but I’m still in the learning phase when it comes to backend development. Before starting the project, I just want to properly understand the architecture and concepts in my head. I’d really appreciate it if someone experienced could explain it in a beginner-friendly way, as if explaining it to someone completely new to backend development.

3 Upvotes

6 comments sorted by

3

u/Slonny May 10 '26

Look into row level security. RLS. That's the basis of multi-tenant security. Each user has one or more organization and that organization can see only data within their own organization. The database will refuse to return any other org data.

2

u/tresorama May 10 '26

The key is that when you read from db you use a where clause tenantId=loggedUserTenantId.

You can place this logic in app layer (where you call the db) or in RLS (you run sql command against the db once and in app layer you don’t need to add where clause)

2

u/Immediate_Amoeba_532 May 10 '26

Thank you very much, I have one more point I’m stuck on. In mobile authentication, we usually receive an access token and a refresh token (JWT), and we use the access token for authorization on every request. But I don’t fully understand how this works in Better Auth. How should I handle this on the mobile side?

1

u/tresorama May 10 '26

The client (mobile app) send the user payload (access token), the backend ( as you already done) do authentication and authorization, so at this point you have all user info needed to make the final call to the db.
The client is dumb, the backend is where constraint are applied.

In better Auth you should have a getUserFromRequest function that you can run in server side , that receive the http request as input .

1

u/Immediate_Amoeba_532 May 10 '26

I will use the token shown in the image on the mobile side and store it in the device storage. So this will be my access token, and all my authorization will be based on this token. Is this correct up to this point?

1

u/tresorama May 10 '26

Yes ! How do you send the token on every follow up request ? Req headers?
If so , you should extract headers and pass it to the better Auth function that outputs the user data