I am storing data from all customers in the same database (multitenant) and thus I need to segregate this data so that one account can’t see data from another.
Currently, I am using the client_id for that. However, when installing the app in different Monday accounts, I realised that the client_id that I get from the Monday token is always the same! This is the information I can get from the token:
Then, the question: should I be using a different id (maybe the account_id) to segregate data in the database correctly between different Monday instances?
The account_id is unique so can be used to segregate accounts data. However, if you want to store tokens your unique key should also contain the user_id as you can’t predict which user in an account will install your app.
Note that the client_id is on the install URL, and thus on every different instance that I install the app, the client_id in the client session token is the same.
I suppose that once published to the marketplace, this behaviour would be different then?
About storing tokens in the DB, we are actually just validating that we are receiving valid calls from the frontend by validating the Monday session token that we send through. I couldn’t find a reason yet to generate one token per user and store in the DB. Is there anything I’m not seeing here?
I am talking about an app (integration) where the code resides on a server. So, it is a server based app. To be able to run under the credentials of a user you need to get a token through the OAuth handshake. I don’t believe you can use the client_id as your token when your app is used in other accounts.
The marketplace link is the same for all users, it is just the installation link
The frontend makes a request passing the sessionToken
The backend validates the sessionToken using the Client Secret of my app
If valid, I persist/read information from/to the database
Now, the problem is that the sessionToken seems to always have my app’s client_id instead of an ID that would represent uniquely the user’s Monday instance.
Yes, that makes sense. I do not have much experience with monday client-side apps. I only can show you how I do this in serverside apps when monday sends a request to my app
I see… well, there’s definitely something different between client-side apps and integrations then, because I can’t validate the token I get in the backend using the signingSecret but I need to use the clientSecret instead.
This is very strange, I don’t understand yet why the client_id in the sessionToken that I get from the frontend is my client ID instead of the user’s instance client ID
Hi @v-appgami
client_id - is the unique public identifier of your app (this is why it is appearing in the installation url and in each request to your app).
For implementing multi tenancy you need to use account_id if you want to store information on the account level, or a combination of user_id + account_id if you want to store data on the user level.
We want to store information on the account level, where each tenant would be one Monday instance (the account, not the user).
What you explained was my understanding as well. However, it seems not possible to store information tied to the account_id because this ID is always pointing our own instance (the one hosting the app installation). No matter what Monday instance is sending requests to our backend, the session token that we get from the SDK method monday.get. I would expect the client_id in this token to be the ID of the account where the request is coming from i.e. the client’s account, not ours.
Could this be a bug, or am I still confused with the concepts? Should I use a different token claim for identifying different customer accounts?