Live data from Hacker News

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

github.com

91–99 of 99 posts

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

#91
post #83

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.

Both have options for column/field level encryption Besides that, you can encrypt in the app regardless of the data storage

> Both have options for column/field level encryption

Cool. Now you just have to store the keys somewhere. And figure out how to authenticate/authorize access to them. :)

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

#92

Earlier quoted context omitted.

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

May I ask how is your experience with authentik?

I use it, I love it! My go to recommendation now!

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

#93
post #82

Earlier quoted context omitted.

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.

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?

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

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

#94
post #83

Earlier quoted context omitted.

Both have options for column/field level encryption Besides that, you can encrypt in the app regardless of the data storage

> Both have options for column/field level encryption Cool. Now you just have to store the keys somewhere. And figure out how to authenticate/authorize access to them. :)

Sure, but you would have had to do that anyway if you didn't pick those RDBMS and rolled your own storage.

Luckily there's established patterns for key management and access control.

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

#95
post #93

Earlier quoted context omitted.

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?

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

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.

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

#96

Earlier quoted context omitted.

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

May I ask how is your experience with authentik?

It’s great. We use it for all of our apps.

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

#97
post #89
post #67

Earlier quoted context omitted.

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

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.

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.

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

#98
post #97
post #89

Earlier quoted context omitted.

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.

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

If every plan is not getting access to at least SSO / RBAC, you are contributing to a weaker security ecosystem that disproportionately impacts non-Enterprise organizations (most organizations).

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

#99
post #97
post #89

Earlier quoted context omitted.

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.

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

This is just insulting your audience, none of us were confused.
Post reply on HN