Hey guys, I saw in your Q1 OKRs that you want to have "Seamless OAuth support" can you shed some light on what this means?

For our current integrations we are hacking the oauth flow

(getting secrets and tokens from browsers and urls)

That's a poor experience

https://docs.airbyte.io/integrations/sources/salesforce is a good example

there is a complex walkthrough to follow

the idea is to have a fully integrated XP within Airbyte

We aren't sure how we are going to it though

It is just an idea right now

Why the question?

We also want to see if we can own the oauth application so users don't have to go through the flow of creating oauth applications (we can give the choice here)

not sure if this is going to be possible because we need to make sure we never exopse the oauth secrets

Cool

We also want our customers to connect their data sources via OAuth

Ideally with an app that we own.

I think the issue is that each connector would have to support oauth

yep, it is not going to be easy indeed

are you down to review the tech spec when we have one avilable?

yeah

i have some time next week to think about how we want to solve it for our own customers, and see how we can implement it on top of current airbyte as well as how airbyte can have this out-of-the-box so we can leverage it.

that may be useful input for your tech spec

yes it would!

cool

I'll post my info in this issue

thanks! we will post the Spec on this ticket as well

Ideally with an app that we own.

@Samuel Gordalina What's the benefit of using your SF App if you don't mind me asking ?

not sure if this is going to be possible because we need to make sure we never exopse the oauth secrets

@Michel Is it even possible with deployable app ? SF app requires full callback url which you can't know in advance because you don't know what ip/port instance of Airbyte will have.

i can't speak to the Salesforce example here, but maybe an easier example is that a user wants to be able to pull their google ads data out of google ads and into their analytics database. Instead of going through the (significant) hassle of getting their own google developer credentials, if they can just authorize the Airbyte account to pull the data from their account, that may be preferable. There's a lot to figure out here, because you can also imagine in the example I just described that the user doesn't want Airbyte to have access to their data (totally reasonable), so then they would still need to get developer credentials but would run the OAuth flow in our UI (but not the hacky version of the flow that we support now). Depending on the integration, sensitivity of the data different solutions make more or less sense, so we're trying to think tactically about which pieces of this flow to enable first.

@ruslan You are correct and that's one piece we don't have a ton of visibility on. One idea would be that we host one piece of the infra on our side to help with the flow.

I wonder if something like that would be possible

WDYT?

With the option of also self-hosting your Oauth Helper if you want to own your own oauth app

@ruslan You are correct and that's one piece we don't have a ton of visibility on. One idea would be that we host one piece of the infra on our side to help with the flow.

Yeah, I had the same idea but that means token is leaking to vendor which some customers may find unacceptable.

yep! agreed, at that point we can just make the oauth helper movable and you can make your own decision wether to use our public one (least effort & can be used by less technical profiles) or the self hosted one (you have to create all the oauth apps)

Hosting our own oauth app/helper is something we're interested on as we want to abstract airbyte from our customers.