Bring back "Bring-your-own-credentials" for OAuth2 authorization schemes

[strunov]

Topic

OAuth2 data sources

Relevant information

As of AirByte 1.4, it appears that all data sources that could be authorized using OAuth2, no longer allow you to manually enter an access_token/refresh_token.

Instead, they must be procured through the regular user OAuth2 flow.

Whilst this functionality is convenient for less technical users, and maintains the data source setup within the AirByte context, it is intrusive in other ways...

1. it requires the AirByte instance to have a publicly accessible endpoint (/auth_flow).
2. Some OAuth2 providers only allow one redirect (snapchat) and it cannot be changed without destroying the app and invalidating existing credentials (snapchat also)

It really makes no sense that we can no longer manually enter our access/refresh tokens which we've obtained by whichever workflows we already had...

Kindly consider.

[marcosmarxm]

Issue reported in Community Slack

[marcosmarxm]

@strunov, thank you for bringing the issue to our attention. The team is currently reviewing it and will get back to you with a proposal for a solution.

[natikgadzhi]

@bazarnov @bnchrch I think we're working on docs for how to do OAuth2 for connectors this week, and if anything, we've expanded the flexibility of it, and you can still bring your own client_id, client_secret, and tokens?

[natikgadzhi]

@strunov so a perfect solution would be to be able to choose between either providing the tokens directly, or providing client_id and secret, and going through the OAuth flow?

[strunov]

@strunov so a perfect solution would be to be able to choose between either providing the tokens directly, or providing client_id and secret, and going through the OAuth flow?

Yes, but just to clarify - in many cases one would require client_id & client_secret even with a refresh_token (as the token has to be exchanged for an access token, which is short lived)

Otherwise, yes, I think having both options is preferable

[bazarnov]

@natikgadzhi I believe there was a reason for not providing the access token option authentication, based on this PR manifest-only migration: #48375 cc @maxi297 Could you please share your thoughts about missing access token authentication for the source-snapchat-marketing?

Generally speaking, I agree that the best approach is to have Airbyte-Own OAuth Apps alongside the ability to switch to the Use my credentials toggle manually.

The current behavior for FE / UI is:

• we now don't show these fields for the connectors that we cover by Airbyte-Own OAuth Apps because of the instance-wide credentials we have Airbyte-wide for this source, removing them will automatically reveal the missing fields providing the ability to use your own credentials. So we need a toggle-switch to control this, or maybe a FF to enable/disable the ability to provide your own credentials. cc @natikgadzhi @bnchrch @lmossman @chandlerprall

[bazarnov]

More information here in the Slack thread: https://airbytehq-team.slack.com/archives/C085DB1V57S/p1737583509789109

[chandlerprall]

So we need a toggle-switch to control this, or maybe a FF to enable/disable the ability to provide your own credentials

A toggle switch makes sense at the first pass, but thinking through:

• on page load/refresh, which side of the toggle the should be shown?
• we added the boolean to indicate if airbyte has an oauth app for a connector
  • we could change that out for a string value of the client id
    • but we want that secret so the sha-256 form
    • except rainbow tables, and any other approach client-side - such as salt - would be visible locally
  • the backend could compare the client ids, however, so maybe update the boolean to hold a trinary value: null (no airbyte creds), using airbyte creds, using user creds
    • doesn't need to (and probably shouldn't) be implemented as a strict trinary, but representing those values https://thedailywtf.com/articles/what_is_truth_0x3f_
    • or, (less preferred IMO) a second boolean to inform which side of the toggle the user is on

[chandlerprall]

it is intrusive in other ways...

it requires the AirByte instance to have a publicly accessible endpoint (/auth_flow).

This isn't blocking, as the redirect is done by the browser which can resolve the endpoint locally, over vpn, etc

The second point is very, very true; as is the fact that the UI now disagrees/competes with any existing configuration