User Credentials vs API Tokens: Choosing the Right Authentication Method for API Requests

omerbialer1 · 2024-07-29T06:38:39.009Z

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:

User authentication (i.e., sending a username and password of a user in the API request)
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:

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?
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!

georgecollier · 2024-07-29T06:46:13.937Z

omerbialer1:

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?

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.

omerbialer1:

Is there any way for malicious actors to “view” the information running behind the scenes between the external system connected to Bubble?

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.

omerbialer1:

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?

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.

omerbialer1 · 2024-07-29T07:14:39.060Z

@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

georgecollier:

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.

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

georgecollier:

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.

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!

georgecollier · 2024-07-29T07:15:51.797Z

omerbialer1:

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?

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.

omerbialer1 · 2024-07-29T07:21:10.121Z

georgecollier:

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.

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?

georgecollier:

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.

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…

georgecollier · 2024-07-29T07:33:49.504Z

omerbialer1:

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

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.

omerbialer1 · 2024-07-29T07:40:33.790Z

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?

georgecollier · 2024-07-29T07:45:14.288Z

omerbialer1:

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?

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…

omerbialer1:

Admin authentication - giving the external system an API token

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

omerbialer1:

User authentication (i.e., sending a username and password of a user in the API request)

… is that Xano never sees plaintext user passwords.

omerbialer1 · 2024-07-29T07:59:55.333Z

Oh I think I get it now!

To begin with I thought you are talking about creating API keys using bubble’s API keys genenrator and then saving these keys in bubble’s db

image1303×362 21.7 KB

Now I understand that you are talking about:

Creating my own tokens in a database
Defining this db privacy to admins only
Pass on to Xano a specific token per BWF
When xano send an API request - pass the token as paremter
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