syun64 commented on PR #8400:
URL: https://github.com/apache/iceberg/pull/8400#issuecomment-1694758682

   > > Our understanding is that the existing Authentication flow in PyIceberg 
is actually an 
[ROPC](https://stackoverflow.com/questions/22077487/difference-between-the-resource-owner-password-flow-and-the-client-credential)
   > 
   > I don't necessarily agree with this interpretation as the original spec 
was written with the expectation that the REST Catalog is the Auth Server. I 
see that this could be interpreted differently if you already have an external 
auth server and are attempting to use that, but that is was not the intent.
   > 
   > We've discussed and are open to allowing for setting the url 
independently, but I think we need to update the REST spec to reflect that 
before we change the clients so as not to introduce inconsistent or 
incompatible changes/behaviors outside of what is defined in the spec.
   
   Hi @danielcweeks ! Thank you very much for the detailed review. I understand 
your point now, and agree that I’ve made a big assumption in my investigation 
that the Rest Catalog was NOT the Auth Server.
   
   I am glad we are still open to the change, because I can see how folks 
(including myself) would be inclined to use an existing, separate Auth Service 
to avoid having to store and maintain user credentials as a part of the Rest 
Catalog.
   
   Regarding the change needed in the Rest Catalog OpenAPI Spec: I think we 
would need to somehow mark the 
[/v1/oauth/tokens](https://github.com/apache/iceberg/blob/25c8e19aed58623b680121bf1ed276452c6aed0f/open-api/rest-catalog-open-api.yaml#L132)
 endpoint to be ‘optional’. The rest of the endpoints will work as is, because 
in the authorization workflow with the external Auth Server, we also already 
have a bearer token attached to the Auth Header on the requests to the other 
endpoints. 
   
   Given that the global security section already has support for both OAuth2 
and BearerAuth types, would adding additional documentation to /v1/oauth/tokens 
endpoint be enough, or is there a better way to communicate that the endpoint 
is optional?


-- 
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]

Reply via email to