Hi Sayantan, Sorry for the delayed response. Although the message has a July 20 Date header, it only appeared on dev@ for me around 18 hours ago.
Yes, I think this is worth clarifying. I noticed that PR #215 has been merged in the meantime. Note: The MCP server has not been released yet, so this is still a good time to define the supported authentication contract before its first release. I think we should separate the Console and MCP cases. The Console already supports OIDC Authorization Code with PKCE. For MCP, service credentials, forwarding a caller's token, and OAuth token exchange are three different modes. Forwarding is sufficient if the incoming token is already intended for Polaris. Token exchange is relevant if the incoming token is intended for the MCP server and the external authorization server needs to issue a separate, possibly narrower, Polaris-audience token. For either delegated mode, I think the contract should explicitly cover token audience, header provenance and trusted-proxy assumptions, credential precedence, token lifecycle, destination restrictions, and whether both the user and the acting MCP service remain visible for authorization and auditing. Polaris can then validate the resulting token and retain the RBAC decision. Could we capture these as explicit supported authentication modes before the first MCP server release? Cheers, Robert On Thu, Jul 23, 2026 at 11:43 PM Sayantan Samajpati <[email protected]> wrote: > Hi Team, > > Starting this thread as per [snazy](https://github.com/snazy)'s > suggestion. > > Currently all the polaris tools (focussing on mcp and the console ui) works > based on client credentials to keep a session active with the REST Catalog. > > For scenarios where the catalog itself is set up with > `polaris.authentication.type=external` - > which disables the internal oauth server, we would like to be able to take > advantage of OAuth2 flows (eg; Token Exchange). > > This helps persist the user session and keeps the entire RBAC in one place > (the catalog), so clients can directly call the catalog APIs with the same > user session. > > Today this is not possible, since in the mcp-server we either need to pass > a long lived client credential or hard coded Bearer token, both of which > will obfuscate who is actually accessing the catalog resources. > > [Issue#173](https://github.com/apache/polaris-tools/issues/197) contains a > diagram and the flow I've in mind, along with what I've had success in > implementing with minimal changes so far. > > Please let me know if this is worth spending some time on. > > Thank You! >
