Security Overview
Explo prioritizes the security of your data and privacy for your customers.
Check out Explo’s Security Trust Center page.
Compliance Certifications
Overview
Database tables that are used for embedded reporting may have many Customer’ data in them. Customers should only ever be able to see their own data via logical separation. To handle this separation, Explo issues tokens that you use when embedding that segment your data to a single Customer. Robust logging of usage will also provide additional auditing to ensure this guarantee.
| Term | Description |
|---|---|
| Explo User | This is a user of Explo that is embedding our product into theirs, likely you |
| Viewer | This is a person that is viewing a dashboard or report embedded from Explo on the Explo User’s website |
| Customer | This is a grouping of viewers that all see the same report when they go to an embedded Explo report. For example, a customer might be an Explo User’s client company with 5 viewers who use that dashboard. |
This solution keeps Explo’s backend and the Explo User’s backend in sync via tokens that are associated with Customers.
How it works
For each Customer, Explo will generate a corresponding token that authenticates them. This token will need to be stored in the Explo User’s backend as well. We suggest adding it as a field to the table where you store the rest of your information about your customers. Alternatively, there is a stateless solution explained below.
Whenever a Customer is created in the Explo User’s backend, an API call should be made to the Explo backend to generate the token for the Customer to then store in the Explo User’s database. Similarly, there are endpoints for deleting tokens when a Customer gets deleted and for refreshing tokens in case they get compromised.
When an Explo User embeds a dashboard, they must provide a token as part of the configuration. This token is associated with the currently logged-in Viewer’s group (Customer) and will be authenticated by Explo’s backend. Explo will then send back the appropriate data for that Customer specifically, segmenting the data as you defined in your dashboard set up.
Keeping track of tokens
There are two options to handle this — a stateful and a stateless option.
[Stateful] Adding Tokens to the Customer’s Table
This requires a small migration on the relevant table. The Explo team will help with the backfilling of tokens for existing Customers.
| name | plan | token |
|---|---|---|
| Pied Piper | enterprise | ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb |
| Hooli | trial | 3e23e8160039594a33894f6564e1b1348bbd7a0088d42c4acb73eeaed59c009d |
| Raviga | trial | 2e7d2c03a9507ae265ecf5b5356885a53393a2029d241394997265a1a25aefc6 |
[Stateless] Querying for Tokens on Demand
Explo exposes APIs for creating, deleting, and refreshing tokens for Customers. The Explo User will need to integrate these corresponding APIs into their backend for when customers are created and deleted or when tokens need to be refreshed.
A stateless way to query for tokens is to call the create customer endpoint, which functions as a “get or create” endpoint. The API will create the Customer and return the corresponding token if the Customer doesn’t exist or just return the token if it exists. This means the Explo User does not need to hold any state about each Customer’s token. In this model, tokens are requested when they’re needed by the Explo User’s embed.