Handling data privacy in Serverless Analytics APIs

Intermediate

Creating an Analytics Dashboard where each user is able to access only certain parts of the data is really easy with Tinybird. You don’t need to build anything specific from scratch. Tinybird is able to provide dynamic endpoints, including specific security requirements per user.

The serverless approach to real-time analytics

Let’s assume you have just two components, the simplest possible stack:

• A frontend application: Code that runs in the browser.

• A backend application: Code that runs in the server and manages both the user authentication and the authorization. Very probably, the backend will also expose an API from where the frontend fetches the information needed.

In this guide, we will cover the different workflows that will handle each user operation with the right permissions, by integrating your backend with Tinybird Auth Tokens in a very simple way.

Creating Auth tokens on user sign-up

The only thing you need to ensure your users have the right permissions on your data is creating a token in Tinybird every time you create a new user in your backend.

Use a token with the right scope:

Replace <your_token> by a token whose scope is TOKENS or ADMIN.

This token will let a given user query their own transactions stored in an events Data Source and exposed in an ecommerce_example endpoint.

Some other noteworthy things you can see here:

• You can give a name to every token you create. In this case, we assigned a name that contains the user_id, so that it’s easier to see what token is assigned to each user.

• You can assign as many scopes to each token as you want, and DATASOURCES:READ:datasource_name and PIPES:READ:pipe_name can take an optional SQL filter (like we did here) to restrict the rows that queries authenticated with the token will have access to.

Available scopes:

Learn here about all the available scopes that you can assign to a token.

If everything goes right, that call will return a JSON containing an Auth token with the specified scopes

All the tokens you create will also be visible in the tokens page in the UI, where you will be able to create, update and delete them.

Auth tokens can be easily managed from your Tinybird Dashboard.

Modifying Auth tokens when user permissions are changed

Imagine one of your users is removed from a group, or something like that, which makes her lose some permissions on the data she can consume. Once that gets reflected in your backend, you can update the user Auth token accordingly as follows:

Pass the token you’ve previously created as a path parameter:

Replace <user_token> by the value of token from the previous response, or copy it from the UI.

Here we’d be restricting the SQL filter of the DATASOURCES:READ:events scope to restrict the type of events the user will be able to read from the events Data Source. This is the response we’d see from the API

Handling Auth tokens on user deletion

Whenever a user is removed from your system, you should also remove the Auth token from Tinybird. That will make things easier for you in the future. That would be as simple as:

If the Auth token is successfully deleted, this request will respond with no content and a 204 status code.

Refreshing Auth tokens

It’s a good practice to change tokens from time to time, so you can automate this in your backend as well. Refreshing a token would be as simple as executing this request for every one of your users:

Learning more about Auth tokens

Take a look at our docs to learn more about our Auth tokens API and all the possibilities this enables when integrating your real-time API endpoints in your applications.