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:
Call bubble login workflow to get the auth token
Call the API with the obtained auth token
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.
@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:
If the call comes from a logged-in user in Bubble, return the data.
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
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.
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.
@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!
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
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
