Hi all, I went ahead and created the first PR (configuration layer):
https://github.com/apache/iceberg/pull/15703 For the curious reader, I also opened a draft PR that encompasses the 5 topics I mentioned in my previous email. This one is not meant to be merged as is (79 files total), but rather to server as a reference: https://github.com/apache/iceberg/pull/15704 Thanks, Alex On Mon, Mar 9, 2026 at 10:54 PM Alexandre Dutra <[email protected]> wrote: > > Hi all, > > Apologies for the delayed response. I'm now ready to integrate the v2 > enhancements into the codebase. > > My proposed approach is to introduce the changes incrementally across > a few PRs, starting with the modifications necessary to bring v2 to > parity with v1: > > 1. Configuration layer > 2. REST / HTTP layer > 3. Test infrastructure > 4. Core grant types (client_credentials, refresh_token, token exchange) > 5. Fully-working OAuth2Manager v2 > > The above list is the minimum required work. The remaining v2 scope > will come after: new grant types, integration tests, documentation, > etc. > > As a reminder, the adopted strategy is to roll out v2 alongside v1 to > avoid impacting current users. The target version for the rollout is > 1.12. > > Does this plan work for everybody? Keeping in mind that with an > incremental approach, the "big picture" may not appear obvious in the > first PRs – so please bear with me as we progress through them. > > Thanks, > Alex > > On Wed, Feb 4, 2026 at 6:52 AM Jean-Baptiste Onofré <[email protected]> wrote: > > > > Hi > > > > I think it’s reasonable to start with an existing lib like nimbus, assuming > > we are clean in terms of dependencies. > > If it’s really an issue (in terms of performance or usability), we can > > always refactore in a second step. > > I would prefer to reduce the effort and get feedback from users. > > Just my 0.02$ > > > > Regards > > JB > > > > Le mar. 3 févr. 2026 à 21:23, Romain Manni-Bucau <[email protected]> a > > écrit : > >> > >> Hi, > >> > >> I'm not sure what you mean by the JRE can't be enough since whatever you > >> do choose it will be enough but if you have to pick something please > >> ensure to not be too opiniated on the underlying stack, jjwt is awesome > >> but brings jackson and some other 3erd parties which comonly lead to mess > >> in projects - already so would add more to the mix. > >> > >> Also try to avoid shades which are not enterprise friendly at all - > >> security, weight, debugging, code analyzis. > >> > >> I had some bad experience with nimbus in terms of perf, this is why I > >> think it can be better to start from scratch, even if it is limited to a > >> few flows and jwt algorithms (JwtValidatorFactory [1] and its sibling > >> signer factory sounds like a valid start to me in terms of scope). > >> > >> [1] > >> https://github.com/yupiik/fusion/blob/master/fusion-jwt/src/main/java/io/yupiik/fusion/jwt/JwtValidatorFactory.java > >> > >> Romain Manni-Bucau > >> @rmannibucau | .NET Blog | Blog | Old Blog | Github | LinkedIn | Book > >> Javaccino founder (Java/.NET service - contact via linkedin) > >> > >> > >> Le mar. 3 févr. 2026 à 19:42, Daniel Weeks <[email protected]> a écrit : > >>> > >>> Alex, > >>> > >>> Thanks for providing such a detailed breakdown. At this point, I think > >>> we should probably just go forward with Nimbus. > >>> > >>> Although we would prefer having a larger community or organization > >>> supporting the library, the shortcomings of the google implementation and > >>> the higher risk of making mistakes building the functionality ourselves > >>> outweigh the maintenance concerns. Worst case, we would have to fork the > >>> library and support it to address a critical vulnerability, but that > >>> seems less likely than making our own mistakes that go unnoticed. > >>> > >>> I support moving forward with an implementation based on Nimbus. > >>> > >>> -Dan > >>> > >>> > >>> On Mon, Jan 19, 2026 at 5:54 AM Alexandre Dutra <[email protected]> wrote: > >>>> > >>>> Hi Romain, > >>>> > >>>> Thanks for your feedback! It touches on two main points: > >>>> implementation effort and security. > >>>> > >>>> On the implementation side, while it's appealing to build everything > >>>> from scratch — especially since Iceberg already has a REST client and > >>>> a JSON mapper — the scope of work is significant. You'd need to create > >>>> all the model classes (for grant types, client authentication methods, > >>>> PKCE methods, etc.), implement JWT parsing, implement the > >>>> request/response classes, their respective serializers/deserializers, > >>>> and of course, add a comprehensive set of tests. > >>>> > >>>> Things would get even harder when/if you start including cryptography > >>>> in the mix (e.g. JWT-based authentication – and BTW, the JRE would not > >>>> be enough anymore). > >>>> > >>>> Based on my experience, with custom impls, the current proposal would > >>>> grow by roughly 40 production Java classes (and another 40 for tests). > >>>> I question whether the community has the appetite to maintain such a > >>>> large amount of custom OAuth2-related code. > >>>> > >>>> The second, critical aspect is security. Although it's often said that > >>>> "OAuth is just a bunch of POST requests," this overlooks the inherent > >>>> risk. A small bug in any custom implementation could have severe > >>>> security consequences. Adhering to the "buy over build" philosophy, I > >>>> think it's always best to pick a battle-tested SDK when there is one. > >>>> > >>>> There are a couple of disadvantages of course, such as the size of the > >>>> resulting JAR file. The Nimbus library and its dependencies introduce > >>>> an overhead of ~2MB. > >>>> > >>>> Another point is whether to shade the library. Given that Nimbus has > >>>> been at version 11.x since 2023 and the changelog [1] mentions no > >>>> breaking changes since then, I think that shading might be > >>>> unnecessary. > >>>> > >>>> Thanks, > >>>> Alex > >>>> > >>>> [1]: > >>>> https://bitbucket.org/connect2id/oauth-2.0-sdk-with-openid-connect-extensions/src/master/CHANGELOG.txt > >>>> > >>>> On Sat, Jan 17, 2026 at 5:52 PM Romain Manni-Bucau > >>>> <[email protected]> wrote: > >>>> > > >>>> > Hi, > >>>> > > >>>> > I'm obviously biaised to have implemented such path (server and client > >>>> > sides) multiple times and in multiple languages but what do you miss > >>>> > in the JRE to implement it without dependencies except a JSON parser? > >>>> > > >>>> > Nimbus can easily conflict cause it is not uncommonly used - and the > >>>> > shades are never a valid solution cause you start breaking CVE > >>>> > scanners, making your images fat etc... > >>>> > > >>>> > So my 2 cts would be to maybe take time to reimplement the few needed > >>>> > flow support (client_credentials, PKCE and token exchange only I > >>>> > think, maybe deviceId later). > >>>> > > >>>> > Romain Manni-Bucau > >>>> > @rmannibucau | .NET Blog | Blog | Old Blog | Github | LinkedIn | Book > >>>> > Javaccino founder (Java/.NET service - contact via linkedin) > >>>> > > >>>> > > >>>> > Le ven. 16 janv. 2026 à 18:02, Alexandre Dutra <[email protected]> a > >>>> > écrit : > >>>> >> > >>>> >> Hi all, > >>>> >> > >>>> >> Following up on our discussion about the Auth Manager v2 proposal and > >>>> >> the pending SDK decision, I wanted to share the results of the > >>>> >> investigation I did today. I also updated the design doc [1] with my > >>>> >> findings. > >>>> >> > >>>> >> We initially considered two options: Nimbus and Google. > >>>> >> > >>>> >> My investigation showed that the Google library only supports RFC > >>>> >> 6749. Therefore, it lacks out-of-the-box support for the token > >>>> >> exchange grant (RFC 8693) and the device code grant (RFC 8628), which > >>>> >> are both essential for us. > >>>> >> > >>>> >> While the missing features could be implemented manually, doing so > >>>> >> seems a waste of time when Nimbus provides all of them. > >>>> >> > >>>> >> Furthermore, the Google library is currently in maintenance mode, and > >>>> >> consequently, it has not received any significant updates for a > >>>> >> considerable period. > >>>> >> > >>>> >> On the other hand, Dan rightly raised concerns about Nimbus's limited > >>>> >> number of committers. That's true. We can however observe that the > >>>> >> project appears "reasonably" active, judging by its recent PRs [2]. > >>>> >> > >>>> >> I would love to have more options on the table. But given how few > >>>> >> candidates we have [3], I've concluded that my initial choice of > >>>> >> Nimbus is indeed the most viable choice – or the "least worst" option, > >>>> >> if you will. > >>>> >> > >>>> >> I'm keen to hear what others think about this, or if I missed anything > >>>> >> in my investigation. > >>>> >> > >>>> >> Thanks, > >>>> >> Alex > >>>> >> > >>>> >> [1]: > >>>> >> https://docs.google.com/document/d/1Hxw-t8Maa7wZFmrlSujm7LRawKsFP3Q31tET_3aRnQU/edit > >>>> >> [2]: > >>>> >> https://bitbucket.org/connect2id/oauth-2.0-sdk-with-openid-connect-extensions/pull-requests/?state=ALL > >>>> >> [3]: https://oauth.net/code/java/
