3 ms·
I made a (rather incomplete) comparision of various OpenID Connect server implementations[0]. Keycloak has over 1M lines of code. LOC isn't everything, but I do
by apitman 3y ago
I made a (rather incomplete) comparision of various OpenID Connect server implementations[0]. Keycloak has over 1M lines of code. LOC isn't everything, but I don't know how you're supposed to avoid a decent number of serious vulnerabilities with that much surface area.
[0]: https://github.com/lastlogin-io/obligator#comparison-is-the-thief-of-joy https://github.com/lastlogin-io/obligator#comparison-is-the-...
- marcosdumay 3y agoMy knee-jerk reaction would be to agree with that. But every single vulnerability I remember being announced for Keycloak was due to some footgun for the authentication protocol. So, I do assess the risk of a less tested but simpler implementation being way higher than of a well tested complex one. What leads to the obvious conclusion that it's best to avoid the protocol completely. But if you don't do that, I'd recommend using the mainstream software.
- merb 3y agowildcard redirects are not kommen and the spec talks about redirect validation
- marcosdumay 3y ago> redirect validation This is an incredibly efficient footgun factory all by itself.
- acdha 3y agoIt’s also how it’s hosted: running as an enterprise Java app means you’re getting a high/critical CVE every week for something you probably don’t even use but which is bundled into something like Wildfly. Looking at it currently, I see SnakeYAML, the Apache SSHD, the H2 database, the Infinispan cache, etc. which are just generic Wildfly features and probably not even enabled, but you have to either be very confident about your ability to make that assertion or patching it frequently. This kind of service really needs to be lean and bundling only the dependencies it uses.