Comment by mooreds | Hacker News Reader

Comment by mooreds | Hacker News Reader

Parent Full thread

You can also choose to self host. Keycloak and FusionAuth (disclosure, I am an employee) let you self host. You then have the user database in your systems.

> And the only way off without a mass password reset is a silent migration in the background: migrate the user when they login.. but we all know that will take months and you will never get 100% to login during the migration period.

Actually, not true. I can't speak for every auth provider, but FusionAuth and Auth0 both let you have the password hashes. If you know the algo (ask your provider!), you can load the hashes (and other ancillary password data like the salt) and your users will never be the wiser.

Here's a guide I wrote about how to migrate off of Auth0: https://fusionauth.io/docs/v1/tech/guides/auth0-migration/ The end goal of the guide is to move to FusionAuth, but the steps to get your password hashes out of Auth0 (the 'Exporting Users' section) will work no matter where you migrate to.

+1.

I maintained and extended a self rolled auth system built on top of django and it was a constant headache. We lost weeks of engineering productivity fighting with keeping the various libraries up to date and running into the usual "forgot password" edgecases.

I spent a few days with FusionAuth for a demo project and once I grokked it I really wished we had used it or something similar instead. Amazing abstraction layer to have at your disposal.

I'm currently implementing Keycloak for my startup. It's not perfectly documented, but I really like all the things it can do for us and how extensible it is.

> It's not perfectly documented

I want to chime in to this too.

If anyone from the Keycloak project is reading: keycloak is awesome, but the documentation is really the most painful part.

The main problem is that it assumes that people installing and/or configuring keycloak already are JBoss/J2EE experts.

Please assume knowledge of GNU/Linux systems, the OAuth/OIDC stuff, LDAP and SAML, but do not assume knowledge of JBoss.

They know about that quite well actually. But there's also Keycloak X in the works which is based on Quarkus. It's not mature enough yet but I hope they tackle a lot of the bad things.

> not perfectly documented

Understatement of the year!

I'd suggest checking out FusionAuth, but I'm a bit biased :) .

I have heard good and bad things about Keycloak, but I know one thing for sure: it's far better than rolling your own auth.

Good luck with your startup!

I understand that you want to promote your solution and you have a disclaimer in the previous comment - and that's great. But if you keep insisting then you should IMHO at least provide some reasons on why your solution may be better than e.g. Keycloak and not just posting the name a couple times and see if it sticks.

Fair point. Here's what I'd say if someone was choosing between Keycloak and FusionAuth:

I believe that FusionAuth has a better developer experience. Everything is an API, the docs are regularly updated (though we can always do better). There's an easy way to set up developer environments to a known state (Kickstart) that I don't believe Keycloak has an analog for.

FusionAuth supports limited memory environments. We have folks running in 384MB of memory. From what I've read, Keycloak wants more resources, though Keycloak X is apparently a good alternative. I don't know if Keycloak X has feature parity.

Theming is easier with FusionAuth, more typical auth flows can be themed, and themes can be entirely API managed: https://www.keycloak.org/docs/latest/server_development/#_th... vs https://fusionauth.io/docs/v1/tech/apis/themes/

If you want to run thousands of tenants,, FusionAuth is better. Compare https://keycloak.discourse.group/t/maximum-limit-of-realms/8... vs https://fusionauth.io/blog/2021/03/29/seegno-thousands-tenan...

Both options offer support (Keycloak via the Redhat SSO package), but you can view our pricing without talking to anyone. I wasn't able to find pricing for Redhat SSO (that's usually not a good sign, but maybe someone who has engaged with them can add more, I could be mistaken and it could be super affordable).

FusionAuth has a 100% free as in beer edition with unlimited enterprise or social connections, users, and tenants. (There are certain usage restrictions; you can't package FusionAuth and resell it without a paid license, for example.)

Keycloak has a large community and is 100% open source. Those are definitely strengths that I want to acknowledge.

It's always good to evaluate software as critical as auth (or payments or notifications, for that matter) with a POC simply because everyone's situation is a bit different and it does get embedded in your systems (source: I picked Stripe for a startup and evaluated moving off multiple times to save money but didn't end up doing so in part because of effort and opportunity cost).

You convinced me. I've been eyeballing Keycloak, will definitely give FusionAuth a shot first. :)

Awesome, would love to hear how it goes.

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

What other FOSS like Keycloak we have available in 2021? Looking to update my knowledge on options

Ones that I've heard of in conversation with customers:

   * IdentityServer (.NET)
   * The ORY suite (hydra, etc)
   * Gluu

I'd say Keycloak is the most common one I hear.

There are about 15 FOSS packages listed here, but you'll need to weed through what is an auth server and what is not: https://en.wikipedia.org/wiki/List_of_single_sign-on_impleme...

There is ForgeRock and WSO2 which we have used in the past. Perhaps they have moved on but would not recommend vs Keycloak.

Awesome, appreciate the perspective. A few qs for you:

My understanding is that you ended up writing java code to extend keycloak. Is that wrong?

Is keycloak resource hungry or have I heard wrong? Have you tried keycloak X? Is that better?

Is there a way to configure a dev environment? Is Terraform the preferred IaC solution?

How many realms do you use typically?

> 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 :)

Thanks for sharing your experience.

Always good to hear from someone who's actually used software rather than second or third hand perspectives.

Reply on news.ycombinator.com