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 >
