-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Source Bing Ads: support oauth #6294
Comments
@sherifnada Public App with appropriate branding created, authorization flow checked. LastPass - Bing Ads OAUth Developer App |
BingAds docs Example of consent url: https://login.microsoftonline.com/common/oauth2/v2.0/authorize? Example of token url: https://login.microsoftonline.com/common/oauth2/v2.0/token where accounts, customer_id, developer_token, user_id, reports_start_date, hourly_reports, daily_reports, weekly_reports, monthly_reports should be forwarded from UI part The BingAds oAuth2 implementation returns refresh_token |
@annalvova05 What is this blocked on? |
@misteryeo |
@bazarnov can we make sure to update the status? It's currently listed as Blocked :) cc: @oustynova |
@misteryeo |
Tell us about the problem you're trying to solve
With the release of Airbyte Cloud, we need to start supporting Oauth for this connector, since it's the recommended way of authenticating users into a SaaS application.
If this connector doesn't support oauth already (i.e: doesn't accept a client_id and client_secret) then we need to update its spec to accept those parameters. There are two ways to do this:
If the connector already supports some auth mechanism like api_key, I suggest that this be a oneof nested inside a top-level field called "authentication":
{ authentication: { type: object oneOf: [ // api key, // oauth ] } }
If the connector only supports webflow oauth, then no changes are needed to the properties format and we will only need to add annotations.
See the connector spec reference in the docs for reference on how a oneof can be implemented.
This should be done in a backwards compatible manner i.e: users currently supplying authentication info in the config's top-level should not be impacted by this change.
Acceptance Criteria
The text was updated successfully, but these errors were encountered: