Hi Yufei, I agree that the deployment model is the first distinction.
For a local, single-user MCP process, using the user's Polaris token is sufficient. There is no separate service identity to model, and token exchange is unnecessary if that token already has the Polaris audience. The shared HTTP/SSE case is not entirely hypothetical any more, though. PR #215 has already merged automatic forwarding of the incoming `Authorization` header when no configured provider supplies one. That gives the MCP server behavior specifically for the remote/shared topology, even though its trust and support contract is not yet defined. I think we should therefore either state that only the local single-user mode is supported for the first release, or define the shared mode explicitly: trusted ingress, token audience, forwarding versus exchange, credential precedence, destination restrictions, and whether the acting service must be visible for auditing. This thread can be that separate discussion; I would prefer not to leave the merged HTTP/SSE behavior as an implicit supported mode. Cheers, Robert On Mon, Jul 27, 2026 at 11:57 PM Yufei Gu <[email protected]> wrote: > 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! > > > > > > > > > >
