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 <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> 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/ >
