But their documentation is really bad, especially in OSS suites. I generally use Claude Code to read their code, find the matching implementation, and try to figure out how to properly configure.
Anyway, if you need self host your IdP, just go for it, you cannot go wrong.
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
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. :)
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.
(i work for Ory as DevRel)
Additional enterprise features that are not available in the open source version such as SCIM, SAML, organization login ("SSO"), CAPTCHAs and more
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.
Sounds great! But buried further in the page,
> Additional enterprise features that are not available in the open source version such as SCIM, SAML, organization login ("SSO"), CAPTCHAs and more
CAPTCHA is not in scope for Kratos, there are already great solutions out there that you can use
> Organizations that require advanced features, enhanced security, and enterprise-grade support for Ory's identity and access management solutions benefit from the Ory Enterprise License (OEL) as a self-hosted, premium offering including: Additional features not available in the open-source version, Regular releases that address CVEs and security vulnerabilities, with strict SLAs for patching based on severity, Support for advanced scaling and multi-tenancy features.
Their dynamic forms stuff is really cool too, always liked how they chose to go about that. Only complaint I really ever had is that while their docs were overall serviceable, I remember some areas were pretty lacking and I had to dig really far to find answers to some fairly common issues.
Obviously you can make a product that only does really good username/password auth for example, but there's always more pressure to implement more things for another use case.
One of my biggest complaints was that one of the Account Recovery flows was just an emailed 6-digit code. So a 1 in 1 million chance that somebody without access to any of your stuff could hack you by just hitting reset and guessing "123456". It's actually surprising how many other Account Recovery flows across the web I have noticed recently that do the same thing. Not sure if Ory has added the option for more entropy in this code as of today's release though it's been a while since I've used it.
Otherwise it was a great project to work with that has tons of knobs to customize. I commend the authors, aeneasr especially. It must be a ton of work to keep up with all of the auth standards and offer this in an Apache2 licensed package all while building a business around it as well!
They could script this to run over a long period of time targeting 1 account, or they could target many accounts at once, and would probably have success.
It recently started to have enterprise only features lately but its licence ensures they are added to the open source product after a set time period. Super nice developer too.
If you are "just" doing first-party login, session, and user mgmt then Ory Kratos is all you need. I would say in the majority of cases you would be fine with just Ory Kratos.
If you want 3rd party integrations, or become an IDP (think "login with $yourcorp"), or you migrate an existing system that relies on OAuth2 that you want to keep, or you have more complex auth flows where OAuth2 shines, then you want Ory Hydra.
If you want a "fine-grained" global, centralized authz system, complex and scalable authz as described by Google Zanzibar, then you want Ory Keto.
If you want to support SAML as well, you want Ory Polis.
If you want a "zero trust" setup, then you want Ory Oathkeeper.
That being said in almost all cases Kratos will be fine and you can pick and choose what you actually need.
- It works and does the job. I appreciate that we got this piece of tech for free when we needed with quickly.
- The doc is clearly written in a way to steer you toward their cloud (fair enough everybody needs to eat). Setting things up is not straight forward even after years of using it.
- Backend driven UI is just weird.
- The founder used to be very opinionated on some things but let bigger issues "rot", better now that they have grown as a business.
- The fact that they wont do SAML in kratos cause its part of their cloud thing and they bought another business speaks volume to me. OSS for ory is a growth strategy, their enterprise version cloud is also not the same as the OSS one.
For OAuth2 we considered Hydra but decided to build it ourselves since we want to host on prem and want to reduce moving parts. We will also likely end up replacing kratos eventually.
TLDR it is a good tech to consider instead of building it yourself. It makes sense for B2C freemium products since all other providers charge per seat. But its not the easiest to setup.
However the newest addition to the Ory ecosystem, called Ory Polis (formerly known as BoxyHQ) does close that gap. It is also Apache2 licensed, do check it out here: https://github.com/ory/polis
Note to self: if I ever need a retirement project, open sourcing a properly architected auth solution would be it.
Would sqlite be a better option?
Unless you're doing something exceedingly simple, you don't just have hashes, you have things like tokens, keys and authorization rules too.
Two factors: the first, that (given the right system permissions) auth data could be fetched from a backup without having access to the system (MySQL/Postgres) directly. Theoretically not a problem if you're salting everything, etc., since you're presumably not storing auth data in plaintext anyway.
Second, no cryptographic verification that nothing has been tampered with? Theoretically possible for someone to e.g. modify the auth data on-disk for the DB to then read and allow auth when it shouldn't.
So I guess at that point the 'solution' would be some form of storage which provides cryptographic verification of its contents so that you can detect tampering, as well as a distributed system with consensus so that if auth data is changed out-of-band then it can be detected and corrected by the other nodes.
In the TypeScript ecosystem, I'd probably take a look at Better Auth though, as the developer experience is really great!
https://help.openai.com/en/articles/9627404-openai-chatgpt-s...
tbh i don't know too much about it other than that they moved away from the apache2 license recently
(disclaimer: I'm working for Ory)
Not sure about Ory these days but I think your OSS code is not the same as the Commercial offering, right?
For example, in a head to head I would prefer Ory because Go is more compatible with the stack I'm working with.
I'm just sharing this as a datapoint. Btw we hired someone who worked at Ory and use Go as well
[1]: https://search.nixos.org/options?channel=25.05&query=zitadel
[2]: https://git.joshuabell.xyz/ringofstorms/dotfiles/src/branch/...
Besides that, you can encrypt in the app regardless of the data storage
Cool. Now you just have to store the keys somewhere. And figure out how to authenticate/authorize access to them. :)
Feel free to message me on the Ory Community Slack if you want to discuss further: https://slack.ory.com/
Luckily there's established patterns for key management and access control.
You wouldn't store plaintext passwords in a database, right? For the same reasons you don't want to store keys, tokens or authorization rules either.
Imagine ssh-agent but distributed with eventual consensus. You don't even need transactions, the data model is simple enough that you can get away with eventually consistent CRDT's.
At Ory, features like high-availability setups, zero-downtime upgrades, large scale multi-tenancy, and formal SLAs are part of the commercial offering. In most cases, if you’re not operating Ory at large enterprise scale, you won’t need those.
It’s a reasonable tradeoff: the commercial offering covers the costs of maintaining those capabilities and helps fund continued open source development. Big organizations that rely on Ory in production should ideally help sustain the ecosystem they depend on.
My take is that Dual Licensing is the better approach here. I.e. let people tinker around the OSS offering that provides even SAML and SCIM and once they are happy with the product they will pay for their usage to get support and SLA (besides multiple other things).
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.
It says "When deploying Ory open-source Servers, protect access to their APIs using Ory Oathkeeper or a comparable API Gateway."
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.