[CountVonGuetzli]

TL;DR: We use Keycloak with millions of users and it works fine. You don't have to shell out for outsourced auth if you would consider a self-hosted solution. You also don't need a team to run it.

I work for a large organization that incorporates multiple other businesses with millions of users under their own domains. After using Auth0 and other SaaS auth providers, we've settled on using Keycloak and are happy with it. Cost, security (you own all data) and extensibility were the driving factors.

+ If you have Java developers, you can extend its features via SPIs. Worked great for some custom authentication and migration flows we had to build for legacy systems.

+ It comes with batteries included: Install it, hook it up and for most cases you are done.

+ Redhat seems quite invested in it, so it has corporate backing. This could also be a bad thing, depending on your view of Redhat and which direction they take the product.

- It is a big pile of java. Since it works so well, even in cluster mode and containerized, we've never had to dig into its internals. But it is still a big pile of java. They are working on a rewrite with Keycloak X, but that is still in development.

[robotdan]

> + Redhat seems quite invested in it, so it has corporate backing. This could also be a bad thing, depending on your view of Redhat and which direction they take the product.

Yes, true. :-) We'll see if IBM feels the same way.

https://www.servethehome.com/red-hat-goes-full-ibm-and-says-... http://techrights.org/2020/08/02/red-hat-layoffs/

[mooreds]

>It is a big pile of java

It looks like Keycloak.X is going to be a slightly smaller pile of java :)

https://www.keycloak.org/2019/10/keycloak-x.html

You say you haven't had to dig into the internals at all, but has having a "big pile of java" even containerized, affected your operations significantly?

[striking]

I've run it inside a container and not experienced tremendous issues with RAM or CPU usage, but this is for very few auth calls per day.

Also, I needed to apply some not-obvious environment / config changes to make it work behind HTTPS and inside a container without /dev/random being remounted.

[CountVonGuetzli]

Not really. But we also haven't had any issues that required taking a closer look. We're used to hosting JVM stuff since our devs produce a lot of scala code.

I'm looking forward to them switching to Quarkus, which will make it more ameneable to be run in containers.

[konha]

Thanks for your insight!

Do you happen to have experience with a large number of realms in Keycloak? I was looking at it a while ago and found conflicting opinions on how suitable realms would be to model multi tenancy in a saas. Mainly for performance reasons I think.

[CountVonGuetzli]

Hmm no, sorry. We only ever had a small number of realms. I would be cautious and test it with the number of realms you intend to use it with. We used locust (https://locust.io/) successfully to do loadtesting on a few of keycloaks auth flows.

[grinich]

Have you had any issues with reliability or downtime in running it yourself? Or any use cases it hasn't supported? Interesting to hear you're running it with so many users!

[CountVonGuetzli]

No issues with reliability.

We did some load testing and noticed that the first thing to become a bottleneck was the database, after running 4k concurrent logins or so. I suspect we'd have to introduce propper postgres connection pooling to overcome that (we were running a single postgres instance).

You do need to watch out for the way it caches things though . I suggest to read the relevant documentation, as it works a bit differently in cluster mode https://www.keycloak.org/docs/latest/server_installation/#_o...

One thing to keep in mind as well is that if you create an SPI extension to cover a spicific usecase, you'll have to add your own metrics collection. It was a bit of overhead to configure in prometheus, since you'll end up having a metrics endpoint to scrape for each SPI.