> 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! > > >
