Forum Academy Marketplace Showcase Pricing Features

Authenticating with included Workflow API using Basic Auth

I’ve four questions about using the embedded workflows that don’t seem easy to resolve. I’ve looked through the documentation for quite some time but still am having difficulty with the following:

  1. Is it possible to use basic auth for accessing my app’s workflow API? (Documentation on using Authentication is here.). I am using www.cloudmailin.com for processing reply-to emails to my app. In testing, all is OK when using the API without authentication; unfortunately, not able to do so with authentication. (I’m connecting to an endpoint created for a workflow named “mg_connect”.
    https://[URL encoded bubble login]:[bubble password]@appname.bubbleapps.io/version-test/api/1.0/wf/mg_connect)

  2. Will auth work without having to specify header values from the remote servers? (One of the remote services I’m trying to use makes post requests to the bubble app but there isn’t the ability to specify header values to specifically call an authentication type.)

  3. Or are there any instructions for using bubble OAuth2 service as stated in the documentation?

Use OAuth 2.0 authentication. This is the prefered method of allowing an un-trusted web application to make requests on behalf of one of your users. Documentation coming soon; for now, contact [email protected] for assistance.

  1. How can you create Login workflows based on the API credentials?

Create sign up / login api workflows. This is useful for building an alternative front-end to your Bubble app, such as a native app that you develop. When an API workflow contains a sign up or a login action, a user ID, a token and an expiration (in seconds) are returned with the response of the call.

The login workflows only show options for login using the standard login & pass but not API tokens.

I’ll answer point by point.

  1. The authentication we support is in the header, as explained in the reference. You should have “Authorization: Bearer API_TOKEN” in the header of your request. What you’re trying to do with https://[URL encoded bubble login]:[bubble password]@appname.bubbleapps.io is not something we ever supported, let us know if you read that somewhere, that’s not good…

  2. We also support for these cases adding a querystring with the API Token as api_token=XXXXX That should do what you want.

  3. At this stage we want to talk with each user that set this up so no, no open documentation yet. So far most people didn’t have to use it, it sounds like what you’re trying to do doesn’t require OAuth2.

  4. I think there is a misunderstanding there. The way it works is that you have an API workflow with 2 parameters ‘email’ and ‘password’ (or whatever you want to name them) and then you have a sign up / login action that uses these params and return a token that can then be used to run workflows as the user. Generally speaking, these Login/Signup workflows should be run without authentication (same as in facebook.com, you sign up without being authenticated at first, since it’s the actual sign up workflow that authenticates you).

Hope this helps.

2 Likes

Thanks for the explanations; this helps out a lot. For questions 1-3, No basic auth, api_token in the url, and it’s OK if we don’t have to use Oauth2.

Question 4 makes sense and is ultimately another API I want to serve. The question is that I can’t see any workflow options that allow me to use (or build) another mechanism for authentication to bubble. In past applications I’ve built (rails, meteor, and react) I’ve created API authentications that use a private and public key combination for authentication. The APIs used both of these values (checking the database and then essentially log in in the remote agent) to login and then access actions.

For my bubble app I have an “Institution Settings” table with a value for the public_api_key, and each “User” has a private_api_key (Institutions have multiple Users). As I’ve done in the past, my plans were to use these two values to login and function how you’ve suggested.

Looking at the login workflow however (see pic), I can’t see any way to actually do this. The login workflow expects an email and password. I suppose I could try a hack by using a unique key value for the email and another private key value for the password, but is that what is intended?

Thanks for the response.

1 Like

Well yeah, we only have one way to authenticate users right now, with email and password. If you’re trying to have a different one it would rely on some slightly ‘hacky’ ways.

One thing to keep in mind though is that once a user has authenticated with such a workflow, it returns the user object and a token that can be used as a API key to run workflows as the user in question (hence being authenticated). The validity of the token depending on the box that you clicked or not in the login action.

1 Like