Today we are launching JWTs for API Endpoints into public beta! With JWTs, you can call Tinybird APIs directly from within the browser, with no middleware or other backend components necessary.
Tinybird is the data platform for real-time analytics. With Tinybird, building real-time solutions involves first ingesting data from multiple sources at scale, then shaping and transforming the data, and finally publishing the data as high-concurrency, low-latency REST APIs. Developers use Tinybird to build a variety of user-facing applications: in-product dashboards, app and web personalization, anomaly detection, and more.
Developers build their applications directly against these REST APIs. Before today, a developer would have to build a proxy or backend service to call the Tinybird API and return data to their front-end application. These proxies required developers to maintain extra code and run extra machines. Latency could also suffer as a front-end application first calls a back-end application, which then calls Tinybird.
Tinybird APIs use tokens to authorize requests. These tokens have attached permissions and other features to ensure data is accessed only by those authorized to do so. It’s a pretty standard way to access an API these days. Those tokens are meant to be used when Tinybird is called from another service but they don’t fit well when you want to use them from a browser (from your dashboard or anything user-facing.)
JWTs enable you to build front-end applications that call Tinybird APIs directly. You don’t need to build a proxy or maintain your own server, and you will see improvements in latency as you can now call Tinybird directly. Just build your front-end application and call Tinybird to render data for your user-facing applications, dashboards, and more.
To read more about how JWTs work, continue reading below.
JWTs are available in every Tinybird Workspace today. You can get started for free with no credit card required. The end-to-end tutorial and product documentation will help you build your first application. If you have any questions, join our Community Slack and ask your questions. We’re ready to help you out.
For even more information on how to build applications with JWTs for API Endpoints, be sure to register for one of our upcoming webinars:
- June 11, 2024: Building Real-Time Leaderboards
- June 20, 2024: Building Customer-Facing Dashboards for SaaS Products
How JWTs work
This new feature allows you to sign JWTs in your existing app auth flow using a shared secret between your app and Tinybird. You can safely pass these JWTs to the browser, allowing your frontend application to call Tinybird API Endpoints directly from the client and avoiding an intermediate back-end hop.
JWTs are already familiar to most application developers and integrate nicely with many existing app authentication flows.
When you build an application, you’ll usually have some components behind authentication. Perhaps you have some APIs that require authentication so you can restrict what data the user can see based on their identity. Typically, you’ll generate a JWT in your backend when the user logs in, pass the JWT to the front-end, and then the front-end will pass that JWT along with the request to the back-end. The back-end validates the JWT and determines whether to allow the request.
This is exactly how JWTs will work with Tinybird, too. When your user authenticates with your app, you will sign a JWT. The JWT must be signed with a shared secret between your app and Tinybird. The JWT is passed directly to the front-end, which can then make calls directly to Tinybird, passing the JWT. Tinybird validates the JWT with the shared secret, guaranteeing that the user has been authenticated from your app.
In the initial beta release, JWTs will be limited to support the two most requested features:
Read-only
To begin with, JWTs will only support read-only scopes of API Endpoints.
This is the most common scenario that Tinybird customers encounter with the three challenges above.
For now, this means that JWTs will not support writing data via the Events API.
Fixed parameters
JWTs will support fixed parameters embedded within the JWT.
These parameters can be added to the JWT during the signing process in your application backend.
When the client calls an API Endpoint using a JWT with an embedded parameter, the value of the parameter is readable at query time. This means that query templating will be able to read the values, making per-token parameters much more flexible. Among other things, this will mean that JWTs support row-level security in multi-tenant applications.
How to use it?
- In Tinybird, find your Admin Auth Token - this is the key that will be used for JWT signing
- In your app backend, use the Admin Auth Token to sign a JWT
- In your app frontend, call the Tinybird APIs passing the JWT as a bearer token
See the docs for code samples in JavaScript and Python, read the user guide, or browse an example repo.
What’s next?
We have a lot of ideas for this feature, but as ever, we’re guided by what our users need. Based on previous feedback, these are future features that are at the top of the list:
Write scopes (e.g., Events API)
The Tinybird Events API allows you to send JSON events to Tinybird using a plain HTTP POST request. This makes it ideal for capturing data from a web application. By extending JWTs to the Events API, we can also enable you to send data from the front-end directly to Tinybird, not just read it.
Caching
Tinybird typically supports applications that need low-latency access to very fresh data. How ‘fresh’ data needs to be depends on your data and application. So you might have situations where ‘5 minutes’ is fresh enough. In these cases, caching starts to make sense.
Rate limiting
When you expose APIs and credentials directly to users, you open up the possibility of misuse (accidental or otherwise). To prevent this, it’s common to apply some rate limiting to APIs, and we’ll investigate first-party support for both global and per-token rate limiting.
Custom domains
Tinybird publishes API Endpoints under a URL like `https://api.tinybird.co/pipes/my_api.json`. They’re pretty clean URLs, but who doesn’t like bringing their own domain? Custom domains will allow you to publish API Endpoints using your site’s domain.
We’re excited to see how you use JWTs. If you have any questions, feedback, or requests, you can reach us in the Community Slack.
