Database tables that are used for embedded reporting have many user groups' data in them. User groups should only ever be able to see their own data via logical separation. Robust logging of usage will also provide additional auditing to ensure this guarantee.
This is Explo's customer that is embedding our product into theirs
This is one of our customer's users that is using a report set up by the customer
This is a grouping of users that all see the same report when they go to an embedded Explo report. For example, a user group might be a customer's client company with 5 users that have an account.
This solution keeps Explo's backend and the customer's backend in sync on tokens that are associated with user groups. We'll call these tokens, synced tokens.
For each user group, Explo's backend will generate a corresponding token that validates them. This token will need to be stored in the customer backend as well. We suggest adding it as a field to the user group (or team) table. Alternatively, there is a stateless solution explained below.
Whenever a user group is created in the customer backend, an API call will be made to the Explo backend to generate the synced token for the customer to then store on their end. Similarly, there will be endpoints for deleting tokens when a user group gets deleted and for refreshing tokens in case they get compromised.
Whenever the customer frontend loads, in addition to the data that is currently pulled from the customer backend, this synced token will be pulled as well. This synced token associated with the logged-in user group will be passed into the embedded web component and authenticated in Explo's backend. Explo's backend will verify the token for the said user group, and send back the appropriate response.
There are two options to handle this — a stateful and a stateless option.
This requires a small migration on the user group (or team) table. The Explo team will help with the backfilling of tokens for existing user groups.
Explo exposes APIs for creating, deleting, and refreshing tokens for user groups. The customer will need to integrate these corresponding APIs into their backend for when user groups are created and deleted or when tokens need to be refreshed.
A stateless way to query for tokens is to call the create user group endpoint, which can function as a "get or create" endpoint. The API will create the user group and return the corresponding token if the group doesn't exist or just return the token if it exists. This means the customer does not need to hold any state about each user group's token.