1

Hey all!

My issue - I want to run a backend workflow in Bubble, triggered by an external system I use

To do this, I need to authenticate the request coming from the external system, and to my understanding, there are two options:

  1. User authentication (i.e., sending a username and password of a user in the API request)
  2. Admin authentication - giving the external system an API token

I am trying to understand the advantages and disadvantages of each method and how to choose the most secure way.

Questions:

  1. Does authenticating with a username and password of a user expose in any way the userā€™s password in the API request? Does this not endanger user information? Is there any way for malicious actors to ā€œviewā€ the information running behind the scenes between the external system connected to Bubble?

  2. If I authenticate with the second method as an admin (with the bubble API key) - doesnā€™t this expose the key to my application in every request? How can I ensure this key remains confidential? After all, it allows admin access

Thanks!

2

If you are passing the username and password to an external provider, you have no control over it. In addition, how would you practically do this? As an app owner, you do not know users passwords - only they do.

Once itā€™s in the hands of the external provider, thatā€™s a question only they could answer, but it would be extremely unwise to send plaintext passwords to the external provider in any case.

If you mean between the external provider and Bubble, itā€™s unlikely to be compromised there as it should be secured by HTTPS.

Yes, if you pass the admin API key to an external provider, they can do anything to your app.

I would do the following:

Create an API Token data type. This should be visible to nobody except admins, using privacy rules. The API token data type just has one field, the ā€˜tokenā€™ (text) and maybe a Type (Option set that tells you what external service uses this API token).

Create a new API Token in the editor, with a random string as the token. Pass this random string to the API.

In the relevant backend workflow, make it publicly accessible without authentication. However, terminate the workflow in the first step only when Do a search for API Tokens:first item is empty, where youā€™re searching for the API token received by the BE workflow.

3

@georgecollier
Thanks for the detailed respones!

For additional context - Im talking about connecting my bubble app to Xano database and wanting to create API calls from Xano to bubble

I guess this is not a good practice but iā€™ve read that I can authenticate in the Backend workflow as a user if I pass the userā€™s credentials via api paremeters. I thouth this might be problematic because it exsposes the credentials in the api request but wasnā€™t sure what best practice

About your solution there is one thing I do not understand. If I understand correctly you mean that I should build a BWF which doesnt need authentication but to terminate it if the token recieved from the API request doesnt exist in a database query, right?

This solution still requires me to save an API key on Xanoā€™s side, and that key will need to be delivered via API request to be used in the database query, no?

Not sure if I understand how is this more secure, it sounds like either way I need to save the API key on Xanoā€™s side, no?

Thanks again!

4

But the API is not an admin API key - it only works for one specific backend workflow, which means that if Xano was compromised, the damage is limited to just that backend workflow.

1 Like
5

Oh, do you mean Its better creating an API key per backendworkflow?

Still I do not understand, why should I save the API keys in bubbleā€™s database instead of passing them to Xano?

Your offer is to enable to run the BWF without authentication while running a search for an API key which was recieved via API request, right? if that is the case than the key should have been saved in xano and its being passed anyway so I guess im missing something in my understanding hereā€¦

6

Youā€™ll need to do both. You save the API key in your Bubble DB, tell Xano somewhere what API key to use, and then Xano will only know that API key which is only useable for one BE workflow.

1 Like
7

Thanks!
In what sense does saving the key in bubbleā€™s db strengthen security? or is it just to keep track with the different keys created?

8

It doesnā€™t - itā€™s necessary for Bubble to be able to check that it is valid.

Letā€™s call the API token a password. Bubble needs to know that the password is correct before permitting something (i.e allowing the BE to run). Also, we only want Bubble and Xano to know the password, and we donā€™t want anyone to be able to search for passwords.

So, if we want Bubble to know the password, we store it in the database, as thatā€™s something only Bubble can see. When protected by privacy rules, nobody can just search for all of the passwords that could be used. Of course, Xano knows the password because you told it (stored it in a variable somewhere, probably.

The advantage compared to thisā€¦

ā€¦ is that Xano never sees an admin API token, and the advantage compared to thisā€¦

ā€¦ is that Xano never sees plaintext user passwords.

1 Like
9

Oh I think I get it now! :crossed_fingers:t3:

To begin with I thought you are talking about creating API keys using bubbleā€™s API keys genenrator :point_down:t3: and then saving these keys in bubbleā€™s db

image
image1303Ɨ362 21.7 KB

Now I understand that you are talking about:

  1. Creating my own tokens in a database
  2. Defining this db privacy to admins only
  3. Pass on to Xano a specific token per BWF
  4. When xano send an API request - pass the token as paremter
  5. In the BWF first step search for that token (I guess i will need to Ignore privacy rules for that - right?) and terminate it if doesnt exist

And in this way Xano will never have any API tokens to my bubble app, rather only specific token to specific tasks

You helped me a alot!!
I really appreciate it