Skip to content
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 Looker: support oauth #6272

Closed
sherifnada opened this issue Sep 19, 2021 · 5 comments
Closed

Source Looker: support oauth #6272

sherifnada opened this issue Sep 19, 2021 · 5 comments

Comments

@sherifnada
Copy link
Contributor

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. I suggest that this be a oneof nested inside a top-level field called "authentication":

{ authentication: { type: object oneOf: [ // api key, // oauth ] } }

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

  1. The connector supports oauth webflow authentication with client_id/client_secret
  2. Oauth properties are annotated properly. See this PR for an example
@sherifnada sherifnada added area/oauth area/connectors Connector related issues labels Sep 19, 2021
@cheyura cheyura self-assigned this Oct 11, 2021
@bazarnov bazarnov self-assigned this Oct 15, 2021
@bazarnov
Copy link
Collaborator

@sherifnada as indicated in this document: https://docs.google.com/spreadsheets/d/17V5aUApkOVOCfGfSAWTXXYYFLN14U0BY5sHZrCn1Q3E/edit#gid=0
and the research gave the same result - the Looker supports the OAuth with Resource Client Credentials (Client_id + Secret) that bounded for the particular user, not any application (private or public), + there is no way to create the public Application that allows us to connect user with Server-Wide client_id + client_secret.

Should we closed this issue without changes to spec? or bring the oauth2.0 into the spec and leave the old option for authentication? WDYT?

@sherifnada
Copy link
Contributor Author

@bazarnov OK let's close this then -- but the tracking sheet isn't very clear about this conclusion. Could you make sure to update it there to retain this context?

@bazarnov
Copy link
Collaborator

Done.

@cheyura
Copy link

cheyura commented Oct 25, 2021

@sherifnada @bazarnov The confusion that this connector is actually requires OAuth - but it is not an OAuth we are interested in but a Resource Owner credentials Grant OAUth.
I suggest in such cases to note in tracking sheet that such a connector does not support and does not require oauth. Makes sense?

@bazarnov
Copy link
Collaborator

@cheyura I agree, but we should add some comment about the cases like: "not an OAuth we are interested in but a Resource Owner credentials Grant OAuth" in the document. See the example for Looker.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Archived in project
Development

No branches or pull requests

4 participants