sungwy commented on issue #791: URL: https://github.com/apache/polaris/issues/791#issuecomment-2670323434
Thank you @flyrain for continuing this discussion, and thanks @dimas-b for sharing your opinion on this issue. I also checked (https://www.rfc-editor.org/rfc/rfc6750) just now that recommended `401` for expiration. And hence, I'm in agreement with you folks that we perhaps won't need to require 419 status code to be implemented by the REST Catalog spec. However, I think there will be a lot of value in continuing this conversation with the Iceberg community through their mailing list to figure out under which status code response, and/or under which error description the Iceberg clients should respond by refreshing the token and retrying again. I think clearly defining that contract will be of value to the community. One thing I disagree with, is the point that we shouldn't be "leaking" the information that a token is expired. Even in the example in [rfc6750](https://www.rfc-editor.org/rfc/rfc6750), the `error_description` contains the rationale for the resource server determining that the request was unauthorized, which in this case is `access token expired`. I do not follow why distinguishing the rationale for denial of access through a status code would be inherently less secure than specifying it through the request body. In a secured HTTPS response, I believe both the status code and the response body would be encrypted through similar means. I also believe that it is the Resource Server's (in our case Polaris) responsibility to determine on what grounds the auth token would be deemed unauthorized, and to communicate that to the client. The JWT would already the expiration time as a part of its claim, and the resource server would be configured against the JWKS of the authorization server to verify the validity of the token. Then, as the resource server has the verified information about the status of the token, I'd argue it is also its responsibility to let the client know on what grounds the token was rejected to let them decide how to proceed. The alternative would be to not inform the client at all by distinguishing between a normal 401 response and an expired one, and let them guess and retry by refreshing the token on any 401 responses. -- 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]
