Is this a good way a web service interacts with a multi-tenant database?

Question

I am trying to make my web service identify specific client data to return as JSON. I am not sure this is the right way, and I'd love some advice.

The way it currently works is:

1. Database table for users with an appropriate company_id where they belong.
2. Upon logging in, an authentication service issues JWT tokens with the company_id in the token payload.
3. The clients sends HTTP requests with the token, after which a service verifies the validity of the token, and then the specific route returns data with SQL doing a WHERE company_id = company_id_in_token .

The red flags I'm running into are:

1. Having user data in the token payload. SSL will negate this, but I am worried about bad design.
2. Having to include a company_id column in every single table for the filtering.

Please, I kindly ask you to rip me a new one.

Answer 1

If you refer to the OpenID specification, it states that you send the id_token, but signs it for later verification. Also, if the upn or sub claim is available, you can infer the tenant from this data. However, in case if the userin question works on behalf of another tenant, special headers are required to infer the tenant, example contextual tenant can be a header that contains the tenant under context.

In case of having tenant id column, it is a good practice to have a tenant id column in the core business objects tables. There will be no tenant id column in a table that is dependent on the core business object, because it by itself doesn't convey any significance.

HTH