API connector and OAuth

Passing a token with two separate APIs and even though the parameter for “grant_type” is the string “authorization_code” for both, it doesn’t seem that it’s passing through, leading to the following errors:

“Invalid grant_type parameter or parameter missing”

Anyone else experiencing this with token-based APIs?

We don’t support Oauth, and hacking that with the API connector wouldn’t work I think.

Even if we retrieved the temporary token via ‘get parameter from URL’ and then ran the API connector to exchange for a long-term token?

If this isn’t possible, and I recognize supporting Oauth means some security things you’d need to work on, is there a shorter term solution by integrating/connecting with a service like https://oauth.io ?

1 Like

My conclusion is that hacking oauth is going to be almost impossible without some help from @emmanuel

Which is a real shame as it really isn’t all that much of a hack. We can use the implicit flow to do the token exchange as @brentsum says. And I have successfully pulled back a JWT which contains the correct access token for google access, but because it is in the URL parameter I can’t decode it with running some code. That was using auth0.com in an attempt to do the heavy lifting.

Maybe using oauth.io would work ?

Not sure if my usecase is the same as the above, but I am not trying to subvert the Bubble auth system, I am just trying to as a user to provide a syndicated logon that will retireive a token to allow we access to their data. This is “link my Google Calendar” style. Or Facebook. Linkedin. etc etc.

Maybe it is my technical naivete, but it doesn’t seem all THAT complicated to be able perform these API calls to get what is essentially a text string. You can pass things in URL parameters.

1 Like

Well it’s not that it’s complicated, it’s that it’s something that touches user authentication, and has to be done carefully, and there are a few things to do before that. Regarding auth0.com, that isn’t a good solution (I did spend quite some time looking at the docs after you asked for it), because it’s not a good approach to rely on something external to manager users. If they were exposing their stuff as an oauth2 service that offers others services through them it’d be great, but they don’t do that.

But that wasn’t what I was asking for.

Not managing bubble users, but managing access to their data via an API. So Google Drive, Facebook Posts etc.

So connecting your Facebook account to your Bubble account so Bubble can post to Facebook, You can’t use Zapier for this because you can only connect a single account.

Agreed. While Blockspring and Zapier allow you to pull public data by connecting through a single social account, we need a way to access a user’s data via an API. Since doing any sort of authentication requires us to register an app with the API, the risk of abuse would be lower than public calls I’d imagine.

and @NigelG the Google Calendar example is a great one. A user should be able to create a calendar event in Bubble and then our app would send the event via Connector to Google’s API.

Looping in another relevant post:

But you need to save their token that are basically their passwords to the service you’re connecting them with. That is a major security thing to deal with. If you don’t, and store them in an insecure way, sure, it works, but one day someone gets hacked, they yell, and you - and us, actually - will have to deal with it. That’s why we’re extra careful there.

What zapier and Blockspring are doing is much easier, because they only use the app owner’s credentials, not the end user’s.

That makes sense. Since all Oauth2 providers send a token the same way, could there be a way for Bubble to treat it as a “secure” data type that only gets sent through API connector? That way it wouldn’t even be a data type that someone could use (or misuse) in the app.

There is always a way, but that’s what I mean when I say it’s some work and needs to be done carefully. We’ll look into this, but can’t commit yet on a deadline.

1 Like

The tokens expire, so it is more about where they are stored locally I would think, but either is a worry.

But it isn’t like this hasn’t been solved elsewhere, but I do appreciate it is a fair amount of work.

Anyone else interested in splitting this as a sponsored feature? Send me a DM and I’ll organize :slight_smile:


What does this mean sponsored feature?

@vega.andrew the Bubble team (for now) will move a feature up in the development queue if a user pays to “sponsor” it. This can be really handy, for example, if you are building a web app for a client and they need something in Bubble that doesn’t exist yet (and they are willing to pay for it).

1 Like

Yes, but on basis that the other sponsors also are willing to put some effort in to do some leg work in testing.