If i need different sub domains for different tenants and wanted to keep users details in tenants database instead of Master, so as to manage GDPR norms, what should i do? could you please help to fix this problem.
Suppose that we build something like SASS: There are 3 companies/partners in our system (A, B, C), every company has their own users and products. There are 2 roles with permissions and root-admin for system. Let authorize for them. Wow @@, hope u make some tutorial about it.
Isn't it a good approach to store the tenant_id inside the JWT token rather that create a separated secret for each tenant? so there is no need for the client to send his tenant_id in the header
Here there are 2 different points. I'm gonna reply to each separately : 1) "Isn't it a good approach to store the tenant_id inside the JWT token.. so there is no need for the client to send his tenant_id in the header" => It is a valid approach, and you can definitely do that. However, in our case, I believe sending the tenant_id in the request header is actually cleaner. By doing this, we can use a middleware to first ensure that the tenant_id is valid before even verifying the token. If we were to store the tenant_id inside the JWT token, we'd have to move the tenant validity check from the middleware to our Guard. This would require the following steps: 1- Decode the token to extract the tenant_id. 2- Check if this tenant_id is valid and fetch the correct secret key for that tenant (assuming each tenant has their own secret key, which is the recommended approach for security when using multiple DBs). 3- Use that tenant-specific secret key to verify the token. 2) "Rather that create a separated secret for each tenant?" => Using the same secret key for all tenants introduces a significant security risk. If that key is compromised, all tenants in your system are at risk. However, by giving each tenant their own secret key (stored in their own database), you minimize the impact of a breach. If one tenant's secret is compromised, it only affects that tenant, while the others remain secure. This adds an important layer of isolation and protection for tenant data. It's worth mentioning, that this reply is specific to our decision of using different DBs for each tenant
![NestJs - Guards & Authentication & Authorization [08]](http://i.ytimg.com/vi/w_ASqSZKhMQ/mqdefault.jpg)
thanks so much.one of the most underrated channel
Thanks, it means a lot !
Great content !!! Every step explained. Nice job. Thank You.
thanks for the content! How would we registers the users for specific tenants ?
Amazing 🤩
My favorite creator dropped a video again! Can't wait to watch it fully
I'm glad :) ❤️
You saved my life!!! please keep going! Thank you so much
I'm glad 😄
Can u revised to use Prisma, postgres, graphql ? 😊
I will keep your suggestion in mind for the future!
Please 🙏
Oh that is a very nice job!!! Thanks!
You're welcome :)
If i need different sub domains for different tenants and wanted to keep users details in tenants database instead of Master, so as to manage GDPR norms, what should i do? could you please help to fix this problem.
Amazing, thank you so much
You're very welcome!
Thanks very much❤
You're welcome !
Thank so much. One question, How can I improve product provider. I have read about dynamic modules to do that, could it work?
You're welcome!
Can you clarify what you mean by improve the product provider?
we need one full project on nestjs with prisma and postgresql following microservice
Suppose that we build something like SASS: There are 3 companies/partners in our system (A, B, C), every company has their own users and products. There are 2 roles with permissions and root-admin for system. Let authorize for them. Wow @@, hope u make some tutorial about it.
Isn't it a good approach to store the tenant_id inside the JWT token rather that create a separated secret for each tenant? so there is no need for the client to send his tenant_id in the header
Here there are 2 different points. I'm gonna reply to each separately :
1) "Isn't it a good approach to store the tenant_id inside the JWT token.. so there is no need for the client to send his tenant_id in the header"
=> It is a valid approach, and you can definitely do that. However, in our case, I believe sending the tenant_id in the request header is actually cleaner. By doing this, we can use a middleware to first ensure that the tenant_id is valid before even verifying the token.
If we were to store the tenant_id inside the JWT token, we'd have to move the tenant validity check from the middleware to our Guard. This would require the following steps:
1- Decode the token to extract the tenant_id.
2- Check if this tenant_id is valid and fetch the correct secret key for that tenant (assuming each tenant has their own secret key, which is the recommended approach for security when using multiple DBs).
3- Use that tenant-specific secret key to verify the token.
2) "Rather that create a separated secret for each tenant?"
=> Using the same secret key for all tenants introduces a significant security risk. If that key is compromised, all tenants in your system are at risk.
However, by giving each tenant their own secret key (stored in their own database), you minimize the impact of a breach. If one tenant's secret is compromised, it only affects that tenant, while the others remain secure. This adds an important layer of isolation and protection for tenant data.
It's worth mentioning, that this reply is specific to our decision of using different DBs for each tenant
Source code: github.com/charbelh3/NestJs-Multi-Tenancy
need more videos
Soon !
can you share this source code? thanks
Sorry for my late response.. here you go : github.com/charbelh3/NestJs-Multi-Tenancy