An analysis of the Keycloak authentication system

(security.humanativaspa.it)

189 points udev4096 | 2 comments | 14 Nov 24 13:32 UTC | HN request time: 0.421s | source

Show context

mickael-kerjean ◴[14 Nov 24 14:57 UTC] No.42136723[source]▶

What if instead of publicly blaming an OSS product, you try to get a support contract with some of the engineers behind it? If your company is too cheap for that, maybe a PR would have been nice?

Having very high expectations when using the software without contributing anything else than public shaming on something that clearly state in the license: "Licensor provides the Work ... WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND" shouldn't be ok, this is quite literally how you make open source developer to burn out

replies(7): >>42136837 #>>42136872 #>>42136966 #>>42137033 #>>42137338 #>>42137517 #>>42137650 #

1. hypeatei ◴[14 Nov 24 15:08 UTC] No.42136872[source]▶

>>42136723 #

Money doesn't guarantee anything, as seen by the recent issue with Okta. If you're using a centralized auth service and expecting no vulns or exploits, you're going to be severely disappointed. These are the juiciest targets and very complex pieces of software.

I don't see an issue with calling out this Keycloak response time either. It's not inherently negative, just stating facts.

replies(1): >>42137874 #

2. debarshri ◴[14 Nov 24 16:32 UTC] No.42137874[source]▶

>>42136872 (TP) #

If you central auth - you have vulnerabilities If you decentralize auth - you have vulnerabilities. It can lead to shadow credentials as well as credential and auth sprawl.

It is about de-risking your approach. Either approaches work until they don't.

↑