HN user
There is a whole giant essay I probably need to write at some point, but I can't help but see parallels between today and the Industrial Revolution.
You might want to give the following Articles a read then: https://www.ufried.com/blog/ironies_of_ai_1/ https://www.ufried.com/blog/ironies_of_ai_2/
It's weird to upload your gpg key to github. gpg is a nightmare mess.
I agree on that, but note that you're also able to use your existing SSH key for signing commits. https://docs.github.com/en/authentication/managing-commit-si...
I cannot agree more on the very mixed bag. In general, Keycloak is a very solid Authorization server. There is a very active community around Keycloak, and if one need an authorization server, they should consider picking it. We use it in an internal multi-tenant environment as a central customer authentication platform.
BUT there's also a lot of pain in using Keycloak, especially when you build on top of it. One of the great things about Keycloak is, that it can be seen as an extendible platform. Nearly everything is customizable. However, it takes a lot of time and effort to learn the programming model and especially the documentation is a PITA. It has been even worse 2 years ago, but it's still a lot of fiddeling around and usual I find myself in reading the Keycloak source (which has a very mixed quality btw.) as no documentation is available.
Multi tenancy is indeed also a hard topic. We heavily utilize multiple realms (I think we should have hit 100 already) for that, but newer developments in Keycloak now offer an additional model based around organizations [1].
One thing that bothers me personally is that the storage model of keycloak does not offer zero-downtime migrations and the work on refactoring it has been paused for now. Since we have a solution based on Keycloak, we deploy Keycloak regulary with every feature. However, the embedded infinispan cache makes this hard on scale as during redeployments Keycloak become unresponsive due to cache leader synchronization and eventually drops some caches, leading to user sessions being terminated. Fortunally Keycloak finally has support for an external Infinispan cache [2] and moved to protocol buffers for serialization [3], which should make upgrades smoother, and grounds the road to zero-downtime deployments.
After all this, let me emphasize that for most of it the Keycloak team is aware and is working hard in moving forward. I started using Keycloak with Version 11 and a lot has changed for the better.
I think Keycloak is somewhat of a no brainer for large teams, but can be a dangerous traps for very small teams.
I would not agree on that. You don't necessarily need a large team for operating Keycloak and smaller teams are probably not that big of an issue. At least not for operating Keycloak. What I feel to be more a problem is, that many (at least of our) clients are not understanding OAuth 2.0 and OIDC well, and therefore puts a larger burdon on support work. Also there must be at least someone very knowledgable of Keycloak to give guidance to the rest of the team, but in general I would not say it's dangerous. We have even a team operating their own keycloak and using our keycloak to perform OIDC federation (don't ask me why tho, I never understood it).
[1] https://www.keycloak.org/2024/06/announcement-keycloak-organ... [2] https://github.com/keycloak/keycloak/issues/28745 [3] https://www.keycloak.org/docs/latest/release_notes/index.htm...