Unfortunately, Xero has custom components, so it's not as easy as opening it in the builder ;(

Referencing PR: #42128

@bnchrch @btkcodedev here instead of disabling OAuth we should add custom OAuth support once @bazarnov 's PR lands in Connector Builder.

We should make the source manifest-only first if it is not already.

Hey! Now that we have OAuth support in Buidler that is coming very soon, I would love to recover source-xero OAuth support on Cloud with custom creds. Is this still needed? @bazarnov @chandlerprall @btkcodedev what should we do here, rebase the PR and change the authenticator spec to include fields and scopes? How should BTK go about it? Wait for the OAUth in Builder support?

It's possible definitely, having this Xero OAuthFlow as an example we had in the past, we can migrate it to the DeclarativeOAuthFlow.

The approximate spec would look like this:

{
    "oauth_connector_input_specification": {
        "type": "object",
        "additionalProperties": false,
        "properties": {
            "consent_url": "https://login.xero.com/identity/connect/authorize?{{client_id_param}}&{{redirect_uri_param}}&response_type=code&{{scope_param}}&{{state_param}}",
            "scope": "accounting.attachments.read accounting.budgets.read accounting.contacts.read accounting.journals.read accounting.reports.read accounting.reports.tenninetynine.read accounting.settings.read accounting.transactions.read assets.read offline_access",
            "access_token_url": "https://identity.xero.com/connect/token?grant_type=authorization_code&{{auth_code_param}}&{{redirect_uri_param}}",
            "access_token_headers": {
                "Content-Type": "application/x-www-form-urlencoded",
                "Authorization": "Basic {{ {{client_id_value}}:{{client_secret_value}} | base64Encoder }}"
            },
            "extract_output": ["access_token", "refresh_token", "expires_in"]
        }
      }
}

How should BTK go about it? Wait for the OAUth in Builder support?

We can have it already if we remove the instance-wide auth credentials (owned by Airbyte earlier) from the DB, the UI will ask for the client_id and client_secret of the Customer's app. Once provided - these values are going to be used for the Authentication of the existing source we have.

The plan is next:

• remove the instance-wide credentials for source-xero from prod db
• update the spec with the config mentioned above for source-xero, set it under the advanced_auth, and fulfill the rest of the spec accordingly
• release the updated source-xero

Alternatively:

• wait until Builder has the feature enabled in the prod
• experiment with the OAuth as much as possible and re-implement it with the above example.

Following the source-xero capabilities we have now, it seems like the OAuth2.0 is not that much useful, in order to be authenticated properly, since having this line should grant the access_token and refresh_token without the user's consent screen, thus - I think there is no need to have the OAuth2.0 flow here at all, if Xero gives an easier way to be authenticated using the simpler grant_type provided.

Following the source-xero capabilities we have now, it seems like the OAuth2.0 is not that much useful, in order to be authenticated properly, since having this line should grant the access_token and refresh_token without the user's consent screen, thus - I think there is no need to have the OAuth2.0 flow here at all, if Xero gives an easier way to be authenticated using the simpler grant_type provided.

Ok Cool, I'll wait for the OAuth support in cloud for proceeding this.

@topefolorunso just moved Xero to manifest-only!

@btkcodedev mind giving this over to @topefolorunso? Tope, look at the manual Baz posted above.

@topefolorunso you're up

On it! @natikgadzhi. Thanks man @btkcodedev, good job so far.