Authentication

Authentication lets your users verify their identity. This lets your control what data they should be allowed to access.

Normally an authentication flow looks something like this:

There are tons of variations of this flow depending on the specific type of system and authentication method. Common for all of them is that the client will receive an access_token that it can use when requesting data from the server.

The purpose of having the user authenticate them selves is that you can provide customized access to specific data on your server. For this to be done in a secure way, authentication must be handled on the server.

Just like with back-ends, toddle does not have an integrated authentication system, but is instead built to work seamlessly with other system.

Storing your access token securely

You might be wondering why the client needs an access token. Why not just send the user credentials with every request? The reason is security. Every time you send a bit of information over the internet or store in the client, you are increasing the chance of that information being compromised by a malicious third party. By using an access token that has a set expiration, you limit the potential harm that an attacker can do if they should be successful in intercepting a request.

Because your access token is strictly confidential it is important that the client stores it in a secure way between requests. In toddle we use a secure HTTP only cookie. This is the most secure option since the token will not be readable by any client side JavaScript code.

Working with access tokens

There are two ways for a toddle application to store an access token in a secure cookie.

You can use the Set Session Cookies action to set a session cookie directly from within your toddle app. This is ideal for users signing in with email / username and password where the server returns an access token directly from the login API.

You can also save an access token by redirecting to /.toddle?access_token=<Your access token> . This is useful for redirect workflows where the actual login happens on a different domain. Services like Supabase, Auth0 and Firebase use this authentication strategy.

If you wish to redirect to a specific page in your toddle app after the token is stored you can set the query parameter redirect_to=<URL>

Now that you have an access token stored in a secure cookie, you can use it to make authenticated requests to an API.

Most APIs today use what is called "token bearer authentication". This means that the API will require each request for data to include an "Authentication" header that starts with the word "Bearer" followed by the access token needed to verify the request.

To achieve this select "Bearer <access_token>" in the Authorization select menu in the API panel.

Each request to the API will now be sent via toddles edge network where the access token will be read from the secure cookie and inserted as an Authentication header.

For this type of authentication to work it is important that the request is "proxied" through toddles edge network. Read more about proxying on the next page.

Working with authentication in the toddle editor

In order for authentication to work properly for applications running inside the toddle editor it is necessary to install a browser plugin. This plugin allows the toddle editor to use cookies when running your application.

Install Chrome plugin

Install Firefox plugin