Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kratos - Cloud native Auth0 open-source alternative (self-hosted)

github.com

Post reply on HN
Print view View original

71–80 of 99 posts

Re: Kratos - Cloud native Auth0 open-source alternative (self-hosted)

#71

Post by tracker1 »

caleblloyd wrote: post #19
fady0 wrote: post #3

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.

Feel free to implement something that sends a UUID, and deal with the complaints instead.

Re: Kratos - Cloud native Auth0 open-source alternative (self-hosted)

#72

Post by mariusor »

nylonstrung wrote: post #68
mariusor wrote: post #40

Earlier quoted context omitted.

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.

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

I didn't ask you to argue, but to present the "data" for your point.

Re: Kratos - Cloud native Auth0 open-source alternative (self-hosted)

#73

Post by otabdeveloper4 »

danudey wrote: post #55
mariusor wrote: post #41

Earlier quoted context omitted.

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.

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. Theor…

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.

Re: Kratos - Cloud native Auth0 open-source alternative (self-hosted)

#74

Post by otabdeveloper4 »

exographicskip wrote: post #13
otabdeveloper4 wrote: post #12

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.

As long as they're salted hashes, they could be stored anywhere right? Would sqlite be a better option?

> 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.

Re: Kratos - Cloud native Auth0 open-source alternative (self-hosted)

#75

Post by otabdeveloper4 »

esafak wrote: post #29
otabdeveloper4 wrote: post #12

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.

authn or authz?

You want to keep both in the same place anyways. (Anybody who compromises authz can now compromise authn, and vice-versa.)

Re: Kratos - Cloud native Auth0 open-source alternative (self-hosted)

#76

Post by trollbridge »

lxdlam wrote: post #58

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,…

Exactly our experience (poor documentation). We switched to Authentik because of this.

Re: Kratos - Cloud native Auth0 open-source alternative (self-hosted)

#77

Post by trollbridge »

trenchpilgrim wrote: post #53
snowfield wrote: post #44

Earlier quoted context omitted.

You can host authentik with one click in docker. It's super easy to set up

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.

I run Authentik in podman; you could also in theory just run it without containers, although that would be obnoxious to set up.

Re: Kratos - Cloud native Auth0 open-source alternative (self-hosted)

#78

Post by yetanother-1 »

trollbridge wrote: post #76
lxdlam wrote: post #58

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,…

Exactly our experience (poor documentation). We switched to Authentik because of this.

May I ask how is your experience with authentik?

Re: Kratos - Cloud native Auth0 open-source alternative (self-hosted)

#79

Post by vinckr »

skrtskrt wrote: post #70
throwaway894345 wrote: post #15

Earlier quoted context omitted.

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.

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 prod…

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...
Post reply on HN