I may be missing something, but I think we first need to distinguish between a local MCP server and a standalone shared MCP service.
In the common local setup, the Polaris MCP server is effectively a client-side component, despite the word “server” in its name. It runs on behalf of a single user and fully represents that user when calling Polaris. In that model, I do not see a separate MCP service principal, so service credentials and token exchange do not appear necessary. The MCP process can simply use the user’s Polaris token. The additional modes you described seem relevant when the MCP server is deployed remotely over HTTP or SSE and shared by multiple users. In that topology, the MCP service becomes an independent trust boundary, and forwarding, token exchange, service identity, trusted proxy assumptions, and auditing both the user and the acting service all become meaningful. The current Polaris MCP server isn't built for this use case. We will need a separate discussion if anyone is interested in it. Could we scope the proposed authentication contract explicitly by deployment model? Otherwise, I worry that we are adding server-side authentication concepts to the local client-side MCP use case where they are not needed. Yufei On Fri, Jul 24, 2026 at 9:57 AM Dmitri Bourlatchkov <[email protected]> wrote: > > Although the message has a July 20 Date header, it only > > appeared on dev@ for me around 18 hours ago. > > Just FYI: The message was held in the moderation queue for 3 days or so. > > Cheers, > Dmitri. > > On Fri, Jul 24, 2026 at 12:43 PM Robert Stupp <[email protected]> wrote: > > > 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! > > > > > >
