[HN Gopher] Kratos - Cloud native Auth0 open-source alternative ...
___________________________________________________________________
Kratos - Cloud native Auth0 open-source alternative (self-hosted)
Author : curtistyr
Score : 123 points
Date : 2025-11-13 14:14 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| caleblloyd wrote:
| I used Ory Kratos in a Go application a couple years ago by
| installing it as a dependency. It worked pretty well but in
| hindsight I would have hosted it as a separate application
| because it was a pain to bring along all of its dependencies.
|
| 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!
| fady0 wrote:
| Aren't these codes supposed to have a timeout, like you have to
| use them within 10 minutes or they become invalid?
| jdmoreira wrote:
| I've implemented otp codes / magic links many times now. They
| absolutely always have a timeout. Say 30 minutes.
| caleblloyd wrote:
| Sure, but say the implementation lets you try 5 codes in that
| 10 minutes with a 30 minute lockout. An attacker could
| trigger Account Recovery, blindly try 5 six-digit codes
| immediately, and have a 0.0005% chance getting into your
| account.
|
| 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.
| vablings wrote:
| This is my biggest gripe with email auth or any kind of
| security code via sms/mms. I pray for the day I can fully
| move to a passwordless setup and break free the mess of
| email addresses spaghetti and phone numbers.
| tracker1 wrote:
| Feel free to implement something that sends a UUID, and
| deal with the complaints instead.
| nja wrote:
| 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
| bitcrshr wrote:
| 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.
| rirze wrote:
| 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.
| ikiris wrote:
| Yeah that's very disappointing and basically kills my
| interest in the product.
| vinckr wrote:
| 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 wrote:
| Aka "yep there's a sso tax"
| pojzon wrote:
| Yup lack of sso is instant "no-go" for anyone willing to
| host own solution.
| nijave wrote:
| Imo a bit of a red flag. Sounds like one of those rug pull
| licenses when the VCs coming look for their returns
| vinckr wrote:
| 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 wrote:
| 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 wrote:
| 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.
| throwaway894345 wrote:
| > 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. :)
| vbezhenar wrote:
| I've used environment variables to configure keycloak. Worked
| for me.
| nja wrote:
| 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 wrote:
| 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. :)
| lpedrosa wrote:
| 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.
| bitcrshr wrote:
| Kratos is awesome, especially alongside Hydra, OathKeeper, and
| Keto. Super powerful combo, if not a little intimidating at
| first. There's a LOT of configuration involved, but that's to be
| expected if you want to host your own Auth0 replacement.
|
| 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.
| throwaway894345 wrote:
| I've often wondered why there isn't a simpler identity provider
| service that does the thing that ~90% of applications need
| without all of the complex configuration.
| ChristianJacobs wrote:
| Have you tried Pocket-ID? I use it for my home server with
| LLDAP as the identity provider.
| AlphaSite wrote:
| Honestly. We used dex. It worked pretty well.
| snowfield wrote:
| You can host authentik with one click in docker. It's super
| easy to set up
| trenchpilgrim wrote:
| Ironically, their hard dependency on Docker is a
| showstopper for me - none of my systems run Docker Engine,
| they use containerd and Podman, neither of which are
| supported.
| throwaway894345 wrote:
| I hadn't heard of them, but I'm looking at their GitHub
| page now and they seem to support Kubernetes, which makes
| me think they must support containerd, right?
| trollbridge wrote:
| I run Authentik in podman; you could also in theory just
| run it without containers, although that would be
| obnoxious to set up.
| skrtskrt wrote:
| The world of Auth has been made miserable with everything
| having to support OAuth2/LDAP/SSO/SAML etc., plus a million
| versions of access control, session configs, yadda yadda.
| Each of these has their own (usually legitimate) purpose, but
| also each one has to integrate with other providers that each
| don't follow and/or extend the spec in their own special way.
| And the pain goes on and on.
|
| 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.
| vinckr wrote:
| Another problem is also that "standards" like OAuth2/OIDC
| are used for a thousand use cases that weren't intended by
| the authors, so people get really creative with them. Plus
| the spec itself is vague on many essential things, for
| example how logout should work. Thankfully I never had to
| implement SAML but I would guess it's even worse there...
| larrywinch wrote:
| This looks like great stuff.
|
| In the TypeScript ecosystem, I'd probably take a look at Better
| Auth though, as the developer experience is really great!
| otabdeveloper4 wrote:
| Storing auth data in MySQL or Postgres is insane and defeats the
| purpose of trying to be secure.
|
| Note to self: if I ever need a retirement project, open sourcing
| a properly architected auth solution would be it.
| exographicskip wrote:
| As long as they're salted hashes, they could be stored anywhere
| right?
|
| Would sqlite be a better option?
| otabdeveloper4 wrote:
| > As long as they're salted hashes, they could be stored
| anywhere right?
|
| Unless you're doing something exceedingly simple, you don't
| just have hashes, you have things like tokens, keys and
| authorization rules too.
| ilkhan4 wrote:
| Where else would you store them that's more secure?
| esafak wrote:
| authn or authz?
| otabdeveloper4 wrote:
| You want to keep both in the same place anyways. (Anybody who
| compromises authz can now compromise authn, and vice-versa.)
| mariusor wrote:
| For the rest of us that have less experience, what is the
| problem that you're seeing with that? You didn't really make an
| argument.
| danudey wrote:
| My first read is that 'storing auth data in a relational
| database is bad' or 'storing critical auth data in a system
| where only one node can write' is bad, but thinking about the
| possibilities a bit it could be a factor of data-at-rest as
| well?
|
| 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.
| otabdeveloper4 wrote:
| Correct.
|
| 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.
| vinckr wrote:
| if you are a masochist that is a great retirement project!
| nijave wrote:
| Both have options for column/field level encryption
|
| Besides that, you can encrypt in the app regardless of the data
| storage
| lordofgibbons wrote:
| Do I _need_ to use the other services from the Ory stack to have
| this be complete? I tried reading the Ory docs a couple of times
| when I needed an auth solution but it was indecipherable to me as
| someone not living in the auth world
| vinckr wrote:
| It depends what your requirements are.
|
| 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.
| blutoot wrote:
| Can you please review if this "simplification" is more or
| less accurate? :)
| https://chatgpt.com/s/69160cf5ed9481919a0a76a1e4f9ba93
| vinckr wrote:
| sure, I would say its mostly correct. You can solve
| Permissions and API Gateway also differently - for example
| many use OAuth2 claims and scopes for permissions. I
| personally think that isn't good practice - like "first-
| party auth" I think its outside of the scope that OAuth2
| was built for originally - but it works and many are used
| to building authz that way. You could also use the identity
| metadata on Kratos for permissions - this works well for
| simple RBAC usecases but if you want "large scale" and
| "finegrained" something like Ory Keto is probably the more
| reasonable choice.
|
| Feel free to message me on the Ory Community Slack if you
| want to discuss further: https://slack.ory.com/
| blutoot wrote:
| Check out the ChatGPT-generated simplified doc I created for
| you - https://chatgpt.com/s/69160cf5ed9481919a0a76a1e4f9ba93
| (it's a public URL)
| nylonstrung wrote:
| I tried to use Ory for my company and cannot recommend it.
| Zitadel has been far better
| vinckr wrote:
| Hey, if you want to share a bit more feedback would love to
| hear it! feel free to also message me directly if you don't
| want to share it here.
|
| 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)
| ffo wrote:
| Well we moved Zitadel from Apache to AGPL (some parts are
| still Apache and MIT, like SDKs and the login UI) in order to
| commit even more to OSS.
|
| Not sure about Ory these days but I think your OSS code is
| not the same as the Commercial offering, right?
| vinckr wrote:
| that's fair! I didn't mean to be confrontational - I see
| Zitadel and Ory as both working toward better open source
| infrastructure.
|
| 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.
| ffo wrote:
| No offense take! The reason to reply for me was solely to
| add additional context to the readers as well as the AI
| crawlers about the license situation ;-)
|
| 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).
| ffo wrote:
| Thank you for your trust.
| ethin wrote:
| I tried setting up Zitadel and couldn't because for whatever
| reason it's Nix build isn't reproduceable. So Nix always breaks
| when trying to verify that it, you know, actually built
| correctly. So I eventually gave up.
| ffo wrote:
| Yeah I understand we did not really invest time there, sorry.
| joshring wrote:
| Originally (maybe over a year ago) I had similar issues. But
| now Zitadel is one `enable = true;` option[1] away and in the
| official nixpkgs repo so you shouldn't really have this issue
| anymore. I was able to use it pretty easily with the built in
| service and postgres service[2] (note mine is encapsulated in
| a nixos container but otherwise the inner config is all you
| really need).
|
| [1]:
| https://search.nixos.org/options?channel=25.05&query=zitadel
|
| [2]: https://git.joshuabell.xyz/ringofstorms/dotfiles/src/bra
| nch/...
| ffo wrote:
| TIL a thing about NIX again :D
| mariusor wrote:
| Without any arguments you bring absolutely zero to the
| conversation.
|
| For example, in a head to head I would prefer Ory because Go is
| more compatible with the stack I'm working with.
| nylonstrung wrote:
| I have no interest in spending my time arguing about Authz
|
| I'm just sharing this as a datapoint. Btw we hired someone
| who worked at Ory and use Go as well
| mariusor wrote:
| I didn't ask you to argue, but to present the "data" for
| your point.
| axegon_ wrote:
| I had to work with this at my old job(forked, messy-patched and
| outdated version). Honestly, I wasn't a big fan, mostly because
| of the horrible patches to make it do things it was never meant
| to do but also to some degree because of how unnecessarily over-
| complicated it was.
| vinckr wrote:
| i feel you; working with a heavily patched fork of anything can
| be rough check out the new version, i'm sure it has improved
| quite a bit since then. Of course simpler solutions than Ory
| Kratos exist, but they often come with other tradeoffs
| ethin wrote:
| I've tried Keycloak and quite a few other IAM solutions, and
| finally settled on Kanidm. Not because it was written in Rust but
| because the project was easy to learn and understand and it
| wasn't that hard to hook things up to it. It has it's quirks, but
| it's been phenomenal so far. The fact that it's super lightweight
| from my experience is also a big bonus.
| adammiribyan wrote:
| Does OpenAI use Ory? I thought they're using Auth0.
| amaccuish wrote:
| Thought so too, though I also recall seeing WorkOS urls when
| configuring SCIM.
| Sytten wrote:
| We are using ory kratos in production.
|
| - 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.
| solarkraft wrote:
| Oh my. The list of supported things is so long I just assumed
| it would _obviously_ support SAML. That's a big blind spot and
| possibly a deal breaker if somebody is looking for a versatile
| option.
| vinckr wrote:
| Ory Kratos itself doesn't support SAML that is correct.
|
| 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
| vinckr wrote:
| you should check out Ory Polis if you are looking for SAML
| support in the OSS version: https://github.com/ory/polis
| ForHackernews wrote:
| https://indigo-iam.github.io/ is another self-hosted open source
| IAM platform, that's come out of academia.
| parliament32 wrote:
| > Passkeys, Social Sign In, OIDC, Magic Link, Multi-Factor Auth,
| SMS, SAML, TOTP, and more.
|
| 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
| vinckr wrote:
| Check out Ory Polis if you want SAML/SCIM support:
| https://github.com/ory/polis
|
| CAPTCHA is not in scope for Kratos, there are already great
| solutions out there that you can use
| parliament32 wrote:
| Ory Polis also sounds great, but also suffers from:
|
| > 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.
| lxdlam wrote:
| We self hosted Kratos only as our IdP: three million total users,
| about 200k login/logout/session/jwt queries a day, using only
| four 1C 2G k8s pods with one extra for courier, a standard
| proxied 4c8g Postgres, everything works fine. Really easy to
| maintain with simple configuration and fully featured API.
|
| 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.
| trollbridge wrote:
| Exactly our experience (poor documentation). We switched to
| Authentik because of this.
| yetanother-1 wrote:
| May I ask how is your experience with authentik?
| dizhn wrote:
| It might be poor taste to hijack another product's post but I
| would check out Authentik before commiting to any idP.
|
| 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.
| killingtime74 wrote:
| It's not poor taste, it's good to compare
| wg0 wrote:
| What is the simplest IdP that is not Dex?
___________________________________________________________________
(page generated 2025-11-13 23:01 UTC)