I've never checked out your product, but we use Keycloak extensively and I can say it is a great Auth solution and I've used several and even built some (poorly).
The only real downside of Keycloak IMO is the documentation. Because it covers so many bases, and is very extensible, the official doc is enormous. There are a lot of lightweight articles about how to use it, I'd use one of those to get started.
Some great things about it are:
- it's widely used, so you can google your way out of most problems
- it does everything. When someone asks if you have 2FA or support Yubikey - the answer is yes.
- it's very extensible. Great APIs, and you also have access to the underlying database should you really need it (we never have, I'm sure some do).
- it's open source. IMO this is a non-negotiable for an auth system
> My understanding is that you ended up writing java code to extend keycloak. Is that wrong?
Depends what you mean by "extend". For many operations, there are REST APIs, e.g. to create a realm (somewhat equivalent to a tenant in the SaaS world - though see below), it's simply POST /auth/admin/realms. There are also more elaborate extensions such as login listeners that if I remember correctly, you would build in Java, but we don't need those.
> Is keycloak resource hungry or have I heard wrong? Have you tried keycloak X? Is that better?
We haven't found it to be disproportionally resource hungry at all. I'm sure there are scenarios we haven't exercised but resource usage not a problem for us. Not fond of the way vendors throw around allegations like that without hard facts.
> Is there a way to configure a dev environment? Is Terraform the preferred IaC solution?
Depends on your own preferences, we just bring it up in a docker container.
> How many realms do you use typically?
Everyone will skin this cat differently, but for us (SaaS):
- one big realm that most tenants use.
- one admin realm for trusted internal access (i.e. our support team).
- one big realm that candidates use (we are an HR platform)
- one realm per tenant that needs SSO. e.g. if they want to authorise login using their own GSuite account, they get their own realm with their own idp.
As someone else pointed out, having large numbers of realms is a weak point of Keycloak. I look forward to us having enough SSO clients that that becomes a problem for us :)
The only real downside of Keycloak IMO is the documentation. Because it covers so many bases, and is very extensible, the official doc is enormous. There are a lot of lightweight articles about how to use it, I'd use one of those to get started.
Some great things about it are:
- it's widely used, so you can google your way out of most problems
- it does everything. When someone asks if you have 2FA or support Yubikey - the answer is yes.
- it's very extensible. Great APIs, and you also have access to the underlying database should you really need it (we never have, I'm sure some do).
- it's open source. IMO this is a non-negotiable for an auth system