bharos commented on PR #7630: URL: https://github.com/apache/gravitino/pull/7630#issuecomment-3070558916
> > > > > 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. > > > > > > Got it. In that case, I can use the MSAL authentication library as recommended here : https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow > > I think then the client side will fetch the token directly from Azure and server only needs to validate it. Thanks for the inputs! > > Different OAuth2 workflow may have different cases to use them. For human, it may be suitable to use auth code flow. For the client of job may be suitable to use client credential. Yes, client jobs can use the client credential flow. I will work on separate PRs to have smaller changes, I will keep this one as a draft and modify in future. Will start with a PR to change the config endpoint to add oAuth configs -- 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]
