Authentication lets your users verify their identity. This enables you to control what data they should be allowed to access.
Typically, 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.
You want to authenticate users to provide customized access to specific data on your server. The only secure way to do this is to handle authentication on the server.
This is also why toddle does not have an integrated authentication system. Instead, we opted for a secure approach and built an API connector where you can connect with authentication systems.
Keep your access token secure
You might wonder why the client needs an access token. Why not just send the user credentials with every request? The reason is security. Whenever you send any information over the Internet or store it in the client, you increase the chance that a malicious third party will compromise it. Using an access token with a set expiration limits the potential harm an attacker can do if they successfully intercept a request.
The client must store your access token securely between requests because your access token is strictly confidential. In toddle, we use a secure HTTP-only cookie. This is the most secure option since any client-side JavaScript code will not read the token.
Install the toddle browser plugin
For authentication to work correctly when working in the toddle editor, it is necessary to install a browser plugin. This plugin allows the toddle editor to use cookies when it runs your application. (Not necessary for users of your application. It's only needed when you build in the editor.)
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 an HTTP-only cookie directly from your toddle app. This is ideal for users who sign in with an email or username and password. This login type has the server return an access token directly from the login API.
You can also save an access token with a redirect to /.toddle?access_token=<Your access token>. This is useful for redirect workflows where logins happen 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 authenticate API requests.
Most modern APIs use "token bearer authentication." This means that the API will require each data request to include an "Authentication" header that starts with the word "Bearer" followed by the access token needed to verify the request.
Add an authorization header in toddle
You need to add a new header to use access_tokens in your authenticated API requests.
Go to the "Headers" section of your API request
Add a new header
Select "Authorization"
This will create an Authorization header where a formula retrieves the value.
The formula's output should be “Bearer access_token,” so we use the “Concatenate” function, where the first argument is “Bearer “ and the second argument is the value of the access token that we are getting using the “Get Http-Only Cookie” formula.
You can continually update the formula depending on your backend's requirements. You can embed an HTTP cookie in headers, query parameters, or path parameters.
Each request to the API will now be sent via toddle's 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 toddle's Edge network. Read more about proxying on the next page.
