I know this thread hasn't gotten a lot of replies yet, but I know there's a lot of interest in more standardized Auth and supporting more flows. I really appreciate the effort you've put into this.
I do want to call out a few points from the doc that we should discuss in more detail. Specifically: *Do we take on an OAuth SDK dependency and if so, which one?* Looking at the two options, I'm a little concerned about the Nimbus library due to the limited number of maintainers. At a cursory glance, it looks like a good library, but relying on a security sensitive library that has effectively one maintainer, is a bit of a red flag. I haven't looked closely at the Google library, but it appears to be in maintenance mode (though they say they will continue to make security related updates). I have a little more confidence in that, but would love it if someone on the Google team could provide any further insight. *What is the future for multi-session management?* You rightly call out that this is primarily (only?) leveraged by Trino, so it might be helpful if they have an alternative, but the intent is to have a clear path to propagate identity for multi-tenant systems. I don't think we can reasonably abandon this unless we have a clear path forward for identity propagation. *Are we creating a new manager or enhancing the existing one?* This was discussed the last time we revisited the auth manager, but I feel like we were leaning more toward integrating the new client and flows rather than a wholesale replacement of the existing auth manager. I'm a little more open to exploring a new manager if the result is a cleaner implementation and we can manage migrating between the two, but I'm not convinced we necessarily need to replace everything. *Do we need to use the REST HTTP Client?* I feel like this is more of a requirement if we were rolling the implementation ourselves rather than relying on a library. We have a number of other libraries that manage their own clients and connections, but I think we want to limit the proliferation in the code we control. Ideally, if we could reuse at least the underlying http client, that would be great, but if the SDK is managing its own client, I don't think that's really a blocker. Overall, I remain strongly supportive of improved and more standardized OAuth2 support (everyone wants refresh token support and the other flows would be beneficial). I'm primarily concerned with making the transition smooth and not introducing auth related inconsistencies for users who already have production systems using the current clients. Looking forward to discussing more tomorrow, but these are my initial thoughts, -Dan On Mon, Jan 12, 2026 at 8:23 AM Alexandre Dutra <[email protected]> wrote: > Hi Christian and team, > > Thank you for your review. This topic has been added to the agenda for > our upcoming catalog sync on January 14th. > > I agree that porting the legacy token-exchange behavior to the new > manager might be unnecessary – I anticipate this will be a key > discussion point on Wednesday. Skipping these features would > significantly simplify the implementation. > > I look forward to our meeting! > > Thanks, > Alex > > On Wed, Jan 7, 2026 at 6:11 PM Christian Thiel > <[email protected]> wrote: > > > > Hello Alex, > > > > Thanks for your persistent initiative! > > > > I’ve gone through the document, and it looks good to me. The plan looks > solid to me, and the selection of flows aligns with what we previously > discussed in the community. I’m not entirely sure we need to migrate the > legacy token‑exchange behaviour to the new Manager. Since this flow is > specific to Iceberg and the endpoint has been deprecated for over 1.5 > years, it might no longer be necessary. > > > > Looking forward to discussing this further in next week's sync! Best, > Christian > > > > > > > > On Mon, 5 Jan 2026 at 16:30, Alexandre Dutra <[email protected]> wrote: > >> > >> Hi all, > >> > >> I hope you're having a great start to the new year! > >> > >> I'm following up on the Auth Manager v2 proposal that I shared a while > >> back. I haven't gotten any feedback or comments on the design doc [1] > >> so far, but I know many of us were away during the last weeks > >> (including myself). > >> > >> It would be awesome if we could chat about it during our next catalog > >> sync meeting on January 14th. Any feedback is welcome, but I'd > >> especially love to hear from folks who use any of the "advanced > >> features" mentioned in the document. > >> > >> Thanks, > >> Alex > >> > >> [1]: > https://docs.google.com/document/d/1Hxw-t8Maa7wZFmrlSujm7LRawKsFP3Q31tET_3aRnQU/edit?usp=sharing > >> On Fri, Dec 12, 2025 at 6:53 PM Alexandre Dutra <[email protected]> > wrote: > >> > > >> > Hi all, > >> > > >> > I would like to resume the discussion around the OAuth2 manager in > >> > Iceberg REST with a new proposal. > >> > > >> > Our last conversation [1] indicated a community preference for > >> > enhancing the existing manager within iceberg-core, rather than > >> > introducing a separate one. We agreed that deprecations and new > >> > dependencies, like an OAuth2 library, were acceptable trade-offs. > >> > > >> > After an extensive PoC, I have developed a design document for what I > >> > am calling the "OAuth2 Manager v2" initiative [2]. > >> > > >> > While the ideal goal was a seamless evolution of the existing manager, > >> > the reality is more complex. The proposal is designed to make the > >> > migration of both configuration and runtime behavior as smooth as > >> > possible, although some adjustments will be necessary. A roadmap with > >> > different steps (deprecation, transition, removal), spanning a few > >> > minor Iceberg versions, is included in the document. > >> > > >> > I welcome your thoughts on the design doc and look forward to > >> > discussing this topic at the next catalog meeting in January 2026. > >> > > >> > Thanks, > >> > Alex > >> > > >> > [1]: https://lists.apache.org/thread/on7xcr838ol0bctxjjfnkjb72rjwnmsk > >> > [2]: > https://docs.google.com/document/d/1Hxw-t8Maa7wZFmrlSujm7LRawKsFP3Q31tET_3aRnQU/edit?usp=sharing >
