Forum Academy Marketplace Showcase Pricing Features

Using bubble for API authentication at the backend

Hello Everyone,

We are building an app whose frontend is built in Bubble. Currently, a logged-in user (who signs up through bubble’s sign up flow) views certain data that is being pulled via an API. This API can also be used by the users directly.

I was wondering is there a way to do the following:

  1. Call bubble login workflow to get the auth token
  2. Call the API with the obtained auth token
  3. The API calls Bubble to validate the token and return the result

I am aware that this can be done if we use AWS Cognito or anyAuth0. However, in that case, the login and signup should also be done using them, increasing the complexity.

Any guidance around this would be quite helpful.

You can use the Bubble Data API along with API key authentication.

@ankur1 Thanks for the response. The data that I am pulling is coming from an external API, so it is not being stored in bubble’s database.

Hey,

I made a video how you can use Bubble.io as a backend system with user-specific bearer token, instead of the API key authentication.

I don’t understand your use case though. As you don’t save the data in the bubble database, what exactly want you to show to the user via the API call from bubble?

Resources:
How to use bubble as backend system (in this example for Adalo):

How to use bubble data outside your application (with differentiation of API-Key and user bearer token):

@Sarah_Biberei Thanks for the response, I will go over the video asap.
Let me try to elaborate on my use case a bit more. So my frontend in Bubble calls an API in the backend (AWS API Gateway) and directly shows the data in a table. Right now, I am calling the API directly without any token. What I was wondering was, what would be an effective way at the API end to make sure:

  1. If the call comes from a logged-in user in Bubble, return the data.
  2. If the call is from an external source(like Postman), authenticate using a token that is generated when the login WF of Bubble is called.

Basically, I am trying to use Bubble inbuilt authorization to authenticate users to use backend APIs. I hope it makes the use case a little more clearer

Nice tutorial!

What if the user has a company and you want to create the API Key to access the information about the company? How could you do that?

Thanks a lot.

Hey,

just to get it right. You use the bearer token from the user, this has nothing to do with the company where he might allocate to.
As long as your data privacy rules allow that this specific user can see this specific information about a company, you are good to go.

Many greetings.

Sarah

1 Like

Hey @ratebunni

Thanks for the clarification. This case is quite the opposite of what I describe in my tutorial.
We had a quick look at the AWS documentation and found this one which might help you Use AWS Lambda authorizers with a third-party identity provider to secure Amazon API Gateway REST APIs | AWS Security Blog

The third party identity provider in this case would bubble.

This being said, we have never done it this way, but we would start with this documentation. So you would basically set up a lambda authorizer function. That function would take the bubble (identity provider) token that is sent with the bubble request and validated with bubble as a third-party identity provider.

If you need help with that, please DM me, maybe we can set something up.

Hope that helps.

Many greetings.

Sarah

I can elaborate on a solution I use later tonight, but just wanted to hear if you are using api gateway v1 (rest) or v2 (https) api?

@simon7 I am using v1 (REST) and am looking forward to your solution

Thanks again @Sarah_Biberei. From a high level your solution makes sense, I am going to go through the link and will update if this approach works.

@ratebunni
Ok, so short description: Upon login I run a workflow against a lambda on AWS - basically a post request to an /auth endpoint that returns a jwt-token with a 1h expiration. This is done server side with a client_credentials oauth2 workflow. In my case I don’t send the users login information - those has already been verified by bubble, so I don’t need them). The returned jwt is saved on the user together with the expiration (remember privacy settings so only current user can see it). The token can now be reused by any workflow to my other lambdas. I have another workflow that checks the expiration. It is run at login, page-changes AND every 5min. If there is <10 min to expiration, I create a new token.

In my case I use http api which have built in jwt authorizer, but for your case you could make a lambda authorizer instead and simple verify the jwt here. Remember to use caching so that your authorizer don’t need to run at every request.

Details:
The /auth endpoint can include data about the user (email, id etc.) which you can save in the jwt. When your authorizer reads the jwt in can pass along the data to any lambda that comes after via a context field, which means you don’t have to parse the jwt in each lambda - its done once in the authorizer and passed on to every lambda after.

It certainly is an advanced method, but its very reliable once setup!

@simon7 I got the crux, I am going to try the same with Cognito, so this approach seems that it will take care of my needs. Thanks

Great, it should be doable. The only downside I see is that you are gonna be handling users at two different places, bubble and cognito - that might become a headache

@Kayami put together a brilliant little video on this:

Is this what you’re looking for?

1 Like

Thank you for posting this! Was looking for this answer for more than 6 months now!
Can you do a quick run through on the Return Data API part? I want to understand what was going on there :slight_smile: