syun64 opened a new pull request, #8400: URL: https://github.com/apache/iceberg/pull/8400
This PR follows up a suggestion that was made on the Slack discussion thread between @Fokko and I. Our understanding is that the existing Authentication flow in PyIceberg is actually an [ROPC (Resource Owner Password Flow), instead of Client Credentials Flow](https://stackoverflow.com/questions/22077487/difference-between-the-resource-owner-password-flow-and-the-client-credential). Assuming that the Auth server is a separate entity from the Rest Catalog, [adopting ROPC introduces a security threat](https://www.scottbrady91.com/oauth/why-the-resource-owner-password-credentials-grant-type-is-not-authentication-nor-suitable-for-modern-applications) to the workflow because in this model, the Rest Catalog is becoming an intermediary that gains access to the client credentials. This mode of relaying the client credentials to the Auth server can be thought of impersonation, rather than authentication. Hence, in this PR we are introducing a capability to make the authentication endpoint configurable so that it can hit a separate address from the Rest Catalog. This way, we could have the PyIceberg session hitting the Auth server for authentication, instead of having the Rest Catalog act as an intermediary for identity verification. And as long as PyIceberg follows the [OAuth2 standard](https://docs.pingidentity.com/r/en-us/developer/ceb1601508084099) (which it does), it will be able to retrieve the access_token from various OAuth providers. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
