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