41–50 of 99 posts
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.
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'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.
Earlier quoted context omitted.
Aren’t these codes supposed to have a timeout, like you have to use them within 10 minutes or they become invalid?
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.
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'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.
Earlier quoted context omitted.
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)
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?
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.
Earlier quoted context omitted.
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…
Can you please review if this "simplification" is more or less accurate? :) https://chatgpt.com/s/69160cf5ed9481919a0a76a1e4f9ba93
Feel free to message me on the Ory Community Slack if you want to discuss further: https://slack.ory.com/
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 thing…
Earlier quoted context omitted.
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?
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 of…
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).
Earlier quoted context omitted.
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.
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…
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.