I’m using Bubble’s API Connector plugin and i have some questions regarding how does it works in the back, is there any deeper documentation/developer settings for checking/modify default functionality.
One of my main problems/needs is to get the refresh token and store it in a secure way/encrypted. There are some posts here with methods for storing tokens in Bubble’s database, but it’s not an Auth best practices.
How does the user’s tokens get stored and where when doing an Oauth login?
Where can i find the response for an authentication? (I.e: request code, token, refresh_token)
Can server/backend functions be executed right after an Oauth login? (ir: for storing tokens in encrypted cookes/session storage)
Where are the user Oauth data stored in the database? How can i delete user’s Oauth credentials (email & id)?
They come through the URL, which is how the API provider sends it back to your app. You then run the necessary workflows to extract it from the URL to store it in your database if you choose to.
It would be stored in your Bubble database or an external database dependent on how you want to store it. You can encrypt it if you want to.
Request Code is in the URL. You then need to run the API calls using the code to get the token and refresh token.
Yes. I take an approach sometimes of taking the Code from the URL and sending it to a backend workflow which is where I would then run the API calls to get the tokens.
Again, where you want to store it would be up to you.
If referencing the credentials that are coming from a plugin like signup/login with Facebook or Google there should be a workflow action that allows you to make changes to the User and remove those credentials…I am not 100% sure on this as I typically am using Oauth not for login/signup, but rather for connecting accounts such as a Google Calendar account.
If you look at privacy rules for a User datatype, if you have the ability in your app to use those social logins, there should be a set of values associated with their social login credentials.
@rico.trevisan ^^^ this kinda stuff is gold. This is the perfect way to tie a native app to a bubble app. No wrapping needed. 3 apps 1 backend. Web. iOS. Android.
That’s the thing, the response not always come in the url, but in a response body. I assume bubble get the token response token from the body, validate it, get the response from that validation and then save the token encrypted in the user.
That’s also inside the response body, with request code i mean HTTP response status codes. As i mentioned, there is the possibility to make a manual auth in bubble, but that means storing the token and refresh token in the user, that isn’t a good practice for security reasons
Is there any way to store them for example in encrypted http cookies? storing them in the user db is not an option right now.
Yes! i recently found that, its under _social_networks, but i think that they are hidden/not available for using it’s values inside the app, the data is stored internally and handled by Bubble’s internal requests/API connector
Is your use case specific to using a social signup like Google or Facebook or are you focused on Oauth from the point of view of adding a User’s connected Stripe Account or any other 3rd party API provider.
I’m using Oauth to integrate Google Drive and Box to users’s accounts and use their APIS to upload/manage files in this platforms.
So the signup is being done by Bubble’s backend and then using API Connector for using these services s API providers
i dont discard the option of oing all the Oauth process manually , i found this cool thread about encryption/decryption of bubble’s data using server side functions.
Also, i don’t know how reliable/error proof is the manual tokens handling , following this for example:
Another interesting thing is to rotate the refresh tokens to make them even more secure, if a malicious user get the refresh token from the user (i.e: Logging in bubble’s editor) it expires and gets another refresh token later, so the refresh token is useless and has to be refreshed:
Put the values into your database and setup the privacy rules properly and they will be secure. Setup workflows with dynamic expressions to use the correct users details from the DB. Setup backend workflows with ignore privacy rules to do the API calls.
If that doesn’t seem secure enough for you, take the added step to use a free encryption plugin to encrypt the values before saving to DB.
i’m testing that approach now, my biggest concern of saving the tokens in bubble db (with privacy settings and encryption included) is that if the dev account gets compromised, a malicious user can get the access data of those services from every user. Is there any other place to store this data?
Paper and pen I suppose, but that probably wouldn’t work that well with a technology solution.
Maybe another database, but there again you will have the same concerns you have here.
You might want to reach out to Bubble support for clarification on what Bubble does to protect your application.
Access to the dev account (which I am assuming would be reference to the User in your Bubble app that is the Admin or app owner) doesn’t mean they can access data related to other users if you set privacy rules up so they can not.
Also, if this dev account is referencing your Bubble application development version (ie: your Bubble account) which gives them access to your applications editor and therefore they can see the data in your app data, this again would be something you should ask Bubble support on how they protect your app.
well, reaching bubble is not a bad option , for example, Bubble stores passwords encrypted and in a different database (that’s why they can’t be seen in the app editor), tokens and api access data should be treated the same way, they must be only accessible by the user and never stored as strings in a db field
Be interested to find out if there is a way to make that possible in Bubble. Would be pretty cool if it were a feature to say when creating a data entry or modifying it to ‘treat this field as a password’ to get that same level of privacy
i found a post response from @NigelG using webtask to run server functions and store tokens
Webtask is not available for new users now, so maybe this can be done directly by bubble’s server-side functions or a third party provider like firebase/cloud functions
This is the type of Token I am referring to…the Access and Refresh Tokens.
If you are referring to the App Client Keys, Secret Keys etc. then this part is applicable
In the Bubble API Connector your keys are stored as text I suppose when setting up different APIs using these various Authentication methods
But any of these parameters are not accessible to anybody except those with access to the app editor, as they are not saved as a Data Type entry or anything like that.
Plus any values you put into the API calls that you label as ‘Private’ like below, these are not accessible from the page as far as I know and should be secure. The only way somebody would have access to these would again be if they had access to your app editor.
Bubble treats these types of values very securely in how they treat them as far as I can tell. In fact, if a template is using the API Connector to setup API calls for use in the template, which for obvious reasons necessitate the use of Private keys and App secret keys etc…these are not possible to transfer to the newly created app from the template…Database values however can be.
Also, if the idea were to keep the APP Client and Secret Keys through webtask, I personally I have no experience with what webtask is or what it can do, but working only in Bubble on the API Connector, it is not possible to get the APP Client or Secret Keys to be used dynamically in most Authentication methods available unless you are doing ‘none or self handled’.
thats true, tokens has strong security in case they go in public, but i still have this extra security concern of someone managing to login as an editor (and having all the client, and secret keys as text) i think that my next step is to search for a way to store api client and secret keys separately .
Thank you for you time Boston! much appreciated , will update the thread if i find a workaround.
.
, i found this cool thread about encryption/decryption of bubble’s data using server side functions.
, following this for example:
, for example, Bubble stores passwords encrypted and in a different database (that’s why they can’t be seen in the app editor), tokens and api access data should be treated the same way, they must be only accessible by the user and never stored as strings in a db field
.
, will update the thread if i find a workaround.