Handling data privacy in Serverless Analytics APIs¶
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:
<your_token> by a token whose
This token will let a given user query their own transactions stored in an
events Data Source and exposed in an
Some other noteworthy things you can see here:
You can give a
nameto 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
PIPES:READ:pipe_namecan take an optional SQL filter (like we did here) to restrict the rows that queries authenticated with the token will have access to.
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.
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:
<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.