[nja]

I've used [Keycloak](https://www.keycloak.org/) in the past for "open-source Auth0" -- though I'm not sure it has ever described itself that way.

Keycloak ended up being quite extensible and powerful, but the UI and data model both sometimes made things more difficult than they had to be... this could be an interesting project to look at.

One bonus (for us) for Keycloak was that it was JVM-based, meaning it was easier to integrate our existing JVM libraries. Though its use of Hibernate was frustrating at times, heh

[throwaway894345]

> One bonus (for us) for Keycloak was that it was JVM-based, meaning it was easier to integrate our existing JVM libraries. Though its use of Hibernate was frustrating at times, heh

I'm pretty frightened of running Java services, not because of the JVM, but because every Java app I've had to operate is infinitely configurable via some poorly documented XML file, and trying to reverse engineer the XML file is often difficult because you have to route through a bunch of Spring Boot magic (preventing an easy grep for configuration options). And on top of that the defaults are rarely system defaults, so even figuring out _where_ the application expects to find its configuration file is nontrivial and logging by default is separated into some unknown number of log streams which each go to a completely different path on disk by default and each one has its own configuration option for telling it to log to stderr.

By contrast, Go services are pretty explicit about where they expect their configuration, they usually log to stderr by default, you can pretty much drop them into any Docker image and run them without issue (no need to custom tune the JVM or bundle up dependencies and ensure the right runtime version). I'm told that the Java world is changing, but in the mean time I will put up with _a lot_ in the way of missing features in order to avoid running a Java application.

Sorry for the rant. :)

[nja]

The nice thing about the Java base here was that instead of trying to solve problems with a mess of configuration, we could just write our own code plugging directly into / replacing parts of Keycloak. Definitely don't disagree with you about the pain of XML, but that wasn't an issue for us here at all

[throwaway894345]

Yeah, I fully believe that there are advantages for your team, and even that Keycloak is much better than the Java apps I have had to operate. I'm just traumatized. :)

[vbezhenar]

I've used environment variables to configure keycloak. Worked for me.

[lpedrosa]

Tbh, I much prefer ORY's API first approach. I looked into Keycloak when I was trying to have a multi-purpose auth server that allowed me to peek into the auth flows.

The sheer complexity of Keycloak's configuration and deployment vs. something like ORY's Hydra was night and day.

And the fact that I could intercept the auth flow through a callback and use their RESTful API to drive it was amazing. No more "package this JAR" and hope that it works. Hydra would run on its own and I don't have to touch it, except when I have to upgrade it.

[vinckr]

Yea part of the motivation to create Ory Kratos was that Keycloak was too clunky and cumbersome for us to use, also hard to scale and a bunch of other issues - so we wrote our own basically.

(i work for Ory as DevRel)

[brulard]

Oh, I wanted to escape the Kratos hell by migrating to Keycloak and you say Kratos was created to actually be a better alternative? Well I have to say I had a very hard time implementing browser flows, configuration is a mess, not everything working through yaml configs works as env var. Documentation is a mess. All in all, it took months what should have been weeks at most. Sorry for the negativity, but it is one of the software pieces I really wish I have avoided.

[vinckr]

sorry to hear that, hope you have a better experience going forward. if you feel like it send me some details on what was most painful and we'll fix it.

[bogomipblips]

Just from looking right now, I'm a bit puzzled by being told right away that it has all open APIs in a warning in the install guide. Would I really want to tell someone to try starting something for our security that is an immediate attack vector?

[vinckr]

if you leave the admin APIs unsecured in production it is an attack vector, not sure what you would prefer being told here?

It says "When deploying Ory open-source Servers, protect access to their APIs using Ory Oathkeeper or a comparable API Gateway."

[bogomipblips]

Since docker/k8s I've started to encounter containers that just start with a default user and no password. The Cuckoo's Egg was published in 1989. Choose a random password if you don't have one and print it to the console.

[rirze]

I'm very familiar with Keycloak, and I don't see this replacing it any time soon. As soon as I read: > The Ory Enterprise License (OEL) layers on top of self-hosted Kratos and provides:

    Additional enterprise features that are not available in the open source version such as SCIM, SAML, organization login ("SSO"), CAPTCHAs and more

I knew it couldn't compete. Good luck to this product.

[vinckr]

You can use other parts of the Ory ecosystem to add these features, such as Ory Polis for SAML/SCIM support: https://github.com/ory/polis

CAPTCHAs aren’t a big help anymore in my personal opinion, but you can easily integrate them on the frontend when using Kratos. The commercial offering just bundles all of this out of the box for you.

If Keycloak fits your needs well and you see no room for improvement, that’s perfectly fine; by all means use what works best for you.

[ikiris]

Aka "yep there's a sso tax"

[pojzon]

Yup lack of sso is instant “no-go” for anyone willing to host own solution.

[esseph]

This is a nightmare for security for companies that aren't big enough to pay the tax - which is most companies.

Every product, every fucking product, if it does anything, should have RBAC and SSO. These are the bare minimum. You want to hold off on SCIM for large customers, fine. Do that.

[vinckr]

These are fair concerns, and I want to clarify what's included versus what's paid.

The confusion here is about two different types of SSO:

_Admin SSO (for managing Ory itself)_ - Ory is fundamentally an API. For self-hosted deployments, you control access however you want - through your infrastructure, reverse proxy, or using Ory Polis. This is not gated.

_Organizations SSO (for your end users)_ - This is the paid feature. It allows your B2B customers to bring their own identity provider. If you're building a SaaS product and BigCorp wants their employees to authenticate using Okta or Azure AD, Organizations handles that federation.

The distinction matters because maintaining integrations with enterprise IDPs is continuous work. For example Google randomly changes their OIDC implementation on a Saturday evening. Someone needs to wake up and fix that. For products serving other businesses at scale, that operational burden is real.

Organizations is one of the few areas where we charge, specifically targeting the B2B SaaS use case. If you're self-hosting for internal use or building a consumer product, you don't need Organizations. If you're selling to enterprises that require SSO, you're generating revenue to support the cost.

[ikiris]

Yeah that’s very disappointing and basically kills my interest in the product.

[nijave]

Imo a bit of a red flag. Sounds like one of those rug pull licenses when the VCs coming look for their returns

[bitcrshr]

I tried Keycloak for a while, it’s really good too. Given it has an admkn dashboard, it’s a bit more “batteries included” than Ory.