That does clarify things. To be honest I thought "Editions" was a product alongside "Cloud".

So Fusionauth looks pretty good - it does a lot more than I need. Though the lack of a "public path" setting is the first roadblock: https://github.com/FusionAuth/fusionauth-issues/issues/88

Would love to know as well. Considering a switch from Cognito here.

We are using Ory Hydra now (but not any of the other components like Kratos, Oathkeeper, etc) and no real complaints so far. It is important to understand though the Hydra is just a component and not an out-of-the-box solution. You still have to implement your own user interface is you plan on doing OIDC login (and not just client_credentials for service authentication). Basically Hydra just takes a self-hosted login/registration/etc UI which you build yourself and wraps it in an OIDC provider. Which is great if you need to build an OIDC provider and want tight control over the user experience and user management (our use case) but don't want to implement all the fussy details of the OAuth2 protocol.

Hydra feels mature. I think it's their longest-developed product so far. Besides breaking changes during big upgrades(v0 -> v1beta -> v1), everything has been painless:

- It runs anywhere with or without containers

- API makes sense, good SDKs are available in all my used languages

- RAM usage is surprisingly low compared to usage and has been great for resource-constrained environments

- Stateless means horizontal scaling is as easy as `replicas++`

- Sub-millisecond response times for some calls, much faster than our previous setup

With Hydra, I know it's the client's fault when OAuth calls fail and not just a buggy server implementation. This is reinforced in dev mode with great errors like:

- The authorization code has already been used

- The request is missing the response_type parameter

- Parameter "nonce" must be set when using the implicit flow

- Redirect URL "https://example.com/callback" does not match

On the flipside, Oathkeeper is not a mature product and has not yet reached v1. There are breaking changes planned [1]. It lacks support for at least one popular usecase (mine) out of the box [2]. Rules can be hard to create and debug. I wouldn't recommend Oathkeeper in its current state unless you're ready to dive in and fix things yourself. Once configured it sticks with the Ory trend: fast, lean, and stable.

Depending on your usecase, Oathkeeper could be swapped out with any IAP like Pomerium or just with your reverse proxy's auth request support + some small custom shim.

I haven't tried Keto (access control) or Kratos (user management) yet. Kratos is on my todo list.

[1] https://github.com/ory/oathkeeper/issues/441

[2] https://github.com/ory/oathkeeper/issues/521

Recently moved away from Keycloak (which I think overall is a great piece of software but was just a PITA for our use case) and my observations:

* Zero-downtime deployments don't really work. They kinda-sorta do but it was too clunky for us to do it effectively during periods when we had significant traffic. Not generally an issue if you are just using out-of-the-box components but if you are deploying custom components (Storage providers, authenticators, etc) then it doesn't work that well.

* It uses an in-memory distributed cache for authentication sessions so if your instance goes down (or you need to shut it down for a major version upgrade) then everyone is logged out. It also seems to have a lot of trouble scaling out to more than ~8 nodes. At the minimum you have to do a lot of tuning of infinispan parameters to get it to work at scale.

* Configuration is kind of a pain because it has to be done through the UI. There is a REST API but it is really hard to work with if you want to do something like deploy a change to an authentication flow configuration. So forget about managing your configs in source control (and prepare for the inevitable issues that happen when configs aren't properly updated with deployment because someone fat-fingers something in the configuration UI).

* There is a LOT of stuff that is hard-coded in the core Keycloak engine that makes customization impossible short of modifying the actual Keycloak source itself and running your own build (not recommended!).

* One small thing that nonetheless drove me crazy is the Keycloak injects a JS snippet into rendered templates to munge the browser history and has no way for you to insert a nonce in the script tag, so setting up CSP headers was way harder than it should have been.

All that said, it was more that Keycloak was not the right tool for our use case (an always-on user-facing identity provider) but if you just need a basic login/registration screen and are fine using Keycloak's built-in components (with maybe just some thumbing) then it works great.