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/
