Creating access token to allow users to use plugin

I’ve built a plugin and I want users to have to provide an access token to use it.

This is the current flow I’m thinking of:

  • Users sign up for my Bubble app
  • I generate an access token for them
  • They install my plugin
  • They need to provide the access token to actually use the plugin

Or if you prefer pictures:

What’s a smart/secure way to implement this type of authentication in a Bubble plugin?

My initial thoughts are that I would:

  • Store the access tokens in the database of my Bubble app
  • Run a GET call in the plugin action to see if the token the user has input is valid

But would be interested to hear thoughts from people who have more experience than me on the subject :slight_smile:

What is the goal of your plugin? What is your goal behind the access token request? Which kind of plugin are your building?

Couple of quick ideas here:

  • Running a backend workflow that logs the user in will return an access token, valid by default for a year

  • Setup a backend workflow that can only be run by an authenticated user - appending the generated access token as an Authorization header and calling from your plugin will invoke the endpoint. Make sure the workflow cannot be invoked without authorization. Return a generic success/error message as per requirements.

Then no need to store the access token your side - as long as the user exists on your Bubble app, them being able to invoke the workflow proves auth. You could perhaps add a search for current user to return some user meta data, again using this as further validation?

You will need to think about token refresh though each year :+1:

I only need to report the site using my plugin. After that is all backend validation. No tokens, just a user specifying their site name and it’s good to go.

With the token method, it’s doable the way you mentioned as well, just a little more work involved. Either way the end-user is still going to need to get that token from you somewhere, right? So having them enter a token isn’t really necessary.

Also note that if you don’t obfuscate your code well, the key portion can be bypassed (also depends on how much functionality is on the plugin itself). So it’s best to include the main-line features with your third-party and allow the site accessing the plugin.

You can easily return the app name and site URL back to your DB, and process your workflows accordingly.

I would probably use a traffic router to do this. Probably a Cloudflare worker. Maybe you could store the key that you provide in a Cloudflare object and then any real API calls that you’re plug in might need to make should actually just get routed to and be executed via the Cloudflare worker which could check to see if the key that the client is passing is valid by validating it through the cloudflare object and passing back the relevant data package

Are you worried about somebody ripping off your code in the client side portion of your plug-in?

Thanks for all the input @Jici, @joshsutheran, @GH5T and @jared.gibb!

Some additional context would indeed be useful. My plugin does the following:

  • Takes some info that the user inputs and passes it to an AWS Lambda function
  • The AWS Lambda function does some stuff with that info
  • And then returns a file to the user of the plugin

This is going to be a subscription product. Once the user subscribes to the product on my website (which will be built with Bubble), they’re going to be provided with an access token. They’ll then input that access token to the plugin.

The point of the access token is to only allow those users who have subscribed to use the plugin.

This sounds promising @jared.gibb, but I’d like to avoid having to use Cloudflare if at all possible :slight_smile:

No not at all. The bulk of the heavy lifting is done in the AWS Lambda function, so no biggie if someone can see my client-side code (although I will of course obfuscate it).

If anyone has any additional insights based on the info above, it would be fantastic to hear :slight_smile: