Dear all, While token exchange is probably the most correct solution semantically, I want to note that there are simpler solutions that don't require token exchange and work out of the box with all IDPs.
Query engines like Starburst and StarRocks both support passing their own token for a user through to the catalog. This requires the catalog to accept tokens with an additional audience, but it is easy to configure. The corresponding docs are here: https://docs.starburst.io/latest/object-storage/metastores.html#oauth-2-0-token-pass-through https://docs.starrocks.io/docs/data_source/catalog/iceberg/iceberg_rest_security/#usage Unfortunately, Trino itself does not support this pass-through yet, but adding it is arguably even less effort than creating a proxy. Note that with token pass-through, the blast radius of a token leakage on the way to the catalog can be larger. If more data sources than just the Iceberg catalog are connected to Trino, they may be accessible with the same token, since Trino would accept its own token back due to a matching audience. For Trino, there is another good option available today: Trino supports external authorization via OPA, and catalogs can provide a lightweight translation layer between their permissions and what Trino expects. With Lakekeeper, we ship this out of the box, and it is also included in the Helm chart. Docs: https://docs.lakekeeper.io/docs/nightly/opa/ Docker Compose: https://github.com/lakekeeper/lakekeeper/tree/main/examples Full example on running this on K8s (kind): https://github.com/c-thiel/open-source-lakehouse Hope this helps! Best regards, Christian On Fri, 20 Mar 2026 at 00:12, Yufei Gu <[email protected]> wrote: > A proxy seems a valid workaround for IDPs lacking RFC 8963 support. Beside > a custom build proxy, we could also leverage some OSS solutions like > Keycloak. > Yufei > > > On Thu, Mar 19, 2026 at 12:57 AM Bharath Krishna <[email protected]> > wrote: > >> I'm running into the same problem and are trying to figure out the right >> approach. A few observations and questions: >> >> On the unsigned subject JWT: Trino's session=USER builds an unsigned JWT >> with iss set to the Trino version string. Most IDPs reject this as a valid >> token exchange assertion, which makes it fragile in practice. >> >> On IDP compatibility: Some widely-used identity providers (e.g., Azure >> AD/Entra ID) don't support RFC 8693 token-exchange natively at all. They >> use proprietary grant types for delegation scenarios, which are >> fundamentally incompatible with the Iceberg token exchange path regardless >> of how the subject JWT is constructed. This seems like a broader problem >> than just fixing Trino's JWT construction. >> >> Current thinking: I'm considering implementing a lightweight proxy that >> handles /v1/oauth/tokens — validating the actor_token (which IS a real >> IDP-signed token from client_credentials) to establish trust in the engine, >> then issuing a short-lived signed JWT with the user identity. The >> rationale: the human already authenticated to Trino, so the >> engine-to-catalog exchange is always M2M and the actor token is the real >> trust anchor. >> >> Is there a better approach today for this class of IDPs, or is a >> proxy/bridge pattern the expected workaround? And does the v2 design have a >> story for IDPs that don't support RFC 8693 natively? >> >> On 2026/03/11 16:07:21 Sander Bylemans wrote: >> > Hey all, >> > >> > Sorry for the radio silence and thank you for the clarification! >> > >> > As far as I can tell, token exchange looks the most promising solution. >> > >> > @Alexandre Dutra if you need a hand with this, I would be happy to help. >> > >> > Kind regards >> > Sander >> > >> > Op vr 27 feb 2026 om 19:09 schreef Daniel Weeks <[email protected]>: >> > >> > > I can provide some context about how this behavior evolved. >> > > >> > > First, it's worth acknowledging that the early approaches to solving >> > > identity propagation used some OAuth features that weren't well >> supported >> > > or relied on rather bespoke implementation decisions. What we >> currently >> > > have isn't ideal and we want to figure out the right path forward as >> we >> > > improve the Auth support in Iceberg and how to integrate that into OSS >> > > engines. >> > > >> > > Trino was one of the earliest (maybe only) systems that was typically >> > > deployed as multi-tenet with support for the REST Catalog as it was >> > > evolving. The challenge was figuring out how to propagate user >> identity >> > > from the engine to the catalog in a secure way that could be trusted. >> > > Given the sessionized design of Trino's catalog interfaces, the >> identity >> > > exchange approach appeared to fit the sessionization and had >> mechanisms in >> > > OAuth to support impersonation from the engine/catalog client. The >> > > implementation was intended to use a service account that could >> communicate >> > > as a trusted relationship with the REST Catalog and then perform >> identity >> > > impersonations through token exchange to act as a user for subsequent >> user >> > > initiated calls. >> > > >> > > I don't know if there is a singular standard for achieving this >> currently >> > > and security concerns make some approaches questionable. For >> example, you >> > > could imagine that an engine could simply forward the token used for >> > > access, but handing off a token between separately governed systems is >> > > generally frowned upon. I've seen many different proposals for how >> > > different systems echange, mint, propogate tokens where multiple >> services >> > > are involved, but it's unclear to me if a singular standard exists >> that >> > > addresses all configurations and security concerns. >> > > >> > > If token exchange remains viable and we just need to improve the >> > > mechanisms to make it more standards compliant (e.g. fix how the >> subject >> > > JWT is constructed), I think everyone would be supportive of that. >> > > >> > > At this point, I believe Trino is the only engine supporting this, so >> it >> > > would be great to find a solution that would carry forward to other >> > > engines. I would also be open to rethinking this if the right >> solution is >> > > to remove complexity from the core library and push session >> management to >> > > the implementing engine. That would possibly simplify much of the >> session >> > > handling we do in core today. >> > > >> > > All that said, we're very open to improving this in any way that >> moves us >> > > toward a more standard approach. >> > > >> > > -Dan >> > > >> > > >> > > >> > > >> > > >> > > On Mon, Feb 23, 2026 at 5:50 AM Alexandre Dutra <[email protected]> >> wrote: >> > > >> > >> Hi Sander, >> > >> >> > >> On the use of the service account for initial communications: this is >> > >> actually by design and is Iceberg's standard behavior. When a REST >> > >> catalog client is created and initialized, it uses the catalog's >> > >> credentials (the service account in your scenario). The user context >> > >> is only relevant after initialization. I believe this is done because >> > >> a catalog client can be shared across multiple user contexts and >> > >> therefore must be initialized with system credentials. Dan may have >> > >> additional context on this design choice. >> > >> >> > >> Regarding your point about Trino constructing its own JWT: I agree. >> > >> That was exactly my earlier concern about the entire interaction >> being >> > >> hard-coded, which explains why users find its configuration >> difficult. >> > >> The token exchange example you found is the Iceberg side of the same >> > >> coin; it's currently undocumented, and only leveraged by Trino. >> > >> >> > >> All of this to say: I'm afraid that what you are trying to achieve >> > >> (multitenancy with token exchange) is simply not possible today. >> > >> People generally work around this issue by doing the token exchange >> > >> off-band, then feeding the resulting token to the catalog config. >> > >> >> > >> But I have good news: this will be re-worked in the v2 version of the >> > >> manager that I am currently preparing. Token exchange is becoming a >> > >> first-class feature, which means you'll soon be able to use it easily >> > >> with providers like Keycloak. If you're interested, the design >> > >> document for v2 is available here: >> > >> >> > >> >> > >> >> https://docs.google.com/document/d/1Hxw-t8Maa7wZFmrlSujm7LRawKsFP3Q31tET_3aRnQU/edit?tab=t.0#heading=h.49o3didcns1c >> > >> >> > >> Hope that helps. >> > >> >> > >> Thanks, >> > >> Alex >> > >> >> > >> On Thu, Feb 19, 2026 at 3:44 PM Sander Bylemans <[email protected] >> > >> > >> wrote: >> > >> > >> > >> > So I've done a setup of Trino with a Rest Catalog underneath >> (Apache >> > >> Polaris). >> > >> > >> > >> > I tried using the USER session property, but for the first few >> > >> communications between Trino and the rest catalog, the service >> account for >> > >> the configured client is used. After that I just get errors and the >> reason >> > >> for that is Trino constructing it's own JWT in this piece of code: >> > >> >> https://github.com/trinodb/trino/blob/1b3a3e39a657642b0c4f76a5439dae859f93b4b1/plugin/trino-iceberg/src/main/java/io/trino/plugin/iceberg/catalog/rest/TrinoRestCatalog.java#L830 >> . >> > >> They set the issuer as the version of trino being used :mind_blown: A >> > >> possible solution could be to correctly construct this JWT, but then >> the >> > >> first few communications (for retrieving metadata) are still in name >> of the >> > >> service account. Don't know if that is desirable? >> > >> > >> > >> > I also experimented with the exchange-token flow against a keycloak >> > >> container, and was able to get this to work. This has been >> implemented by >> > >> keycloak for about a year now. I would be up for fixing the USER >> session >> > >> code in Trino, if you guys have any feedback? Particularly about the >> first >> > >> few calls of communication being done by the service account? Should >> that >> > >> be documented better in Trino then? >> > >> > >> > >> > I know the token-exchange flow is also implemented by the >> OAuth2Manager >> > >> here: >> > >> >> https://github.com/apache/iceberg/blob/de3125afe64fc2b171a52b6e884c72f901e3cba1/core/src/main/java/org/apache/iceberg/rest/auth/OAuth2Manager.java#L220 >> . >> > >> How would one use this in the Trino implementation? Because there the >> > >> session is just converted, no new catalog seems to be created for >> the user. >> > >> > >> > >> > Thanks for your responses! >> > >> > Sander >> > >> > >> > >> > >> > >> > Op di 17 feb 2026 om 23:49 schreef Daniel Weeks <[email protected] >> >: >> > >> >> >> > >> >> Hey Sandor, >> > >> >> >> > >> >> I agree with Alex that you should try using the 'USER' session >> > >> property, but this relies on token exchange (RFC 8693), which is a >> less >> > >> used, if not obscure, OAuth2 extension. We've seen some >> inconsistencies >> > >> across IDPs. >> > >> >> >> > >> >> I would emphasize that this is a really important feature for >> proper >> > >> identity attribution/propagation. We're hoping to improve this type >> of >> > >> support across the board, so please follow up if there are >> alternatives >> > >> already in Trino or we should consider a different approach. >> > >> >> >> > >> >> -Dan >> > >> >> >> > >> >> On Tue, Feb 17, 2026 at 7:52 AM Alexandre Dutra < >> [email protected]> >> > >> wrote: >> > >> >>> >> > >> >>> Hi Sander, >> > >> >>> >> > >> >>> In Apache Iceberg, the OAuth2 layer indeed only supports static >> tokens >> > >> >>> or a client ID/secret pair. The only supported grant type is >> > >> >>> client_credentials; the token exchange grant is reserved >> strictly for >> > >> >>> token refreshes, not for initial authentication. >> > >> >>> >> > >> >>> I suspect that the Trino behavior you mentioned might be related >> to >> > >> >>> Trino's "iceberg.rest-catalog.session" property, specifically >> when it >> > >> >>> is set to "USER" [1]. >> > >> >>> >> > >> >>> In this configuration, Trino generates a JWT at catalog >> > >> >>> initialization, and uses the token exchange grant to exchange >> that JWT >> > >> >>> against another token [2]. >> > >> >>> >> > >> >>> However, this feature is poorly documented and has recently been >> > >> >>> reported by users as being complicated to set up correctly [3]. >> The >> > >> >>> exchange looks like a home-grown client assertion, but it's not >> > >> >>> configurable, and I suspect it doesn't work well with some IDPs. >> > >> >>> >> > >> >>> For more information on the Trino specifics, your best bet might >> be to >> > >> >>> reach out directly to the Trino mailing list or Slack channel. >> > >> >>> >> > >> >>> Hope that helps. Thanks, >> > >> >>> Alex >> > >> >>> >> > >> >>> [1]: >> > >> >> https://trino.io/docs/current/object-storage/metastores.html#iceberg-specific-metastores >> > >> >>> [2]: >> > >> >> https://github.com/trinodb/trino/blob/38406672349c33d4902bca7a5ebd380b6b382802/plugin/trino-iceberg/src/main/java/io/trino/plugin/iceberg/catalog/rest/TrinoRestCatalog.java#L484-L510 >> > >> >>> [3]: https://github.com/trinodb/trino/issues/26320 >> > >> >>> >> > >> >>> On Mon, Feb 16, 2026 at 5:03 PM Sander Bylemans < >> [email protected]> >> > >> wrote: >> > >> >>> > >> > >> >>> > Hey all, >> > >> >>> > >> > >> >>> > Currently looking into integrating Iceberg into our >> dataplatform >> > >> setup. However, I'm experiencing some issues with oauth2 integration, >> > >> specifically with Trino. I would like Trino to pass a JWT to the >> Iceberg >> > >> catalog I'm using, or use the exchange-token flow, to enable true >> multi >> > >> tenancy. However when I'm looking at the apache implementation of >> this, it >> > >> expects a static token or a credential. The exchange flow is >> implemented >> > >> but it is unclear to me how one would configure a RestSessionCatalog >> that >> > >> would use that flow... >> > >> >>> > >> > >> >>> > Is that something that is broken? I have found several >> discussion / >> > >> PR's regarding this topic: >> > >> >>> > - https://github.com/apache/iceberg/issues/12196 >> > >> >>> > - https://github.com/apache/iceberg/pull/12362 >> > >> >>> > - >> https://lists.apache.org/thread/j49320100wtpp15dv197fdjqw2hwl91j >> > >> >>> > >> > >> >>> > Thanks for the info! >> > >> >>> > >> > >> >>> > Kind regards >> > >> >> > > >> > >> >
