jerqi commented on PR #7630: URL: https://github.com/apache/gravitino/pull/7630#issuecomment-3060091439
> > OAuth have two concepts. Authorization server and resource server. The Gravitino server should be a resource server instead of authorization server. So Gravitino shouldn't maintain the token. Iceberg community has a similar discussion. You can see https://lists.apache.org/thread/twk84xx7v0xy5q5tfd9x5torgr82vv50 and https://lists.apache.org/thread/o4qmrm5jx50mk1mqws0t9f1z2op4gvvm > > @jerqi That makes sense. In this case, Gravitino UI is the client. And we want to make OAuth2 requests to 3rd-party like Azure. Here Gravitino server is not maintaining the token, just the Gravitino UI is maintaining it in the browser localStorage. > > Gravitino server does get the initial callback with the token, at /oauth/callback , but all it does is to validate the token and forward it to the ui/oauth/callback to store on the browser local storage > > So Gravitino as a resource server doesn't maintain or issue the tokens in this case Gravitino don't need to forward the HTTP request to the OAuth server, too. It means that we don't need to implement the `/api/oauth/config`, `/api/oauth/authorize` , and `/api/oauth/callback`. If web UI want to know the url information, we can configure them in the configuration, you can refer to the code in the class `ConfigServlet`. Another thing is that AuthenticatorFilter is only applied to path `/api`. So We don't need to fliter the path `/config` by hand. For this code, you can see `GravitinoServer.class#155Line`. For another point, maybe we should create a new OAuth authenticator for Azure OAuth implementation. Current implementation can be used for Keycloack. -- 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]
