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