Logto - The better auth and identity infrastructure

[loulou2852]

---

• Title: Logto - The better auth and identity infrastructure

---

• Main Page: https://logto.io
• Git: https://github.com/logto-io/logto
• Licence: MPL-2.0
• Docker: Yes

---

• Summary: Logto is an open-source alternative to Auth0 and an OIDC (OAuth 2.0) provider designed for modern applications and SaaS products, supporting both authentication and authorization. SAML is also supported.

---

• Notes: I like it because it has very fresh UI, it's easy to connect to existing apps with plenty of integrations. It has security in mind with CAPTCHA. For me, it's more user-friendly than keycloack.

---

• Alternative to / Libhunt link: https://alternativeto.net/software/logto/
• Screenshots:
  
  

[robi]

Looks just like a Node App - https://github.com/logto-io/logto/blob/master/Dockerfile

Can test it in the LAMP app.

[walski]

I've been trying to package this for the last couple of days and have definitively gone waaaaay to far down the rabbit hole.

The big challenge is that logto in it's current incarnation is inherently a multi-tenant app. The way it manages it's multi-tenancy internally is by creating a master DB role and then 1 new DB role per tenant in Postgres and also relying on pg's Row-Level-Security a lot.

Unfortunately we cannot create new Postgres roles as a Cloudron app. I've also tried to find ways Cloudron could fix these, e.g. by allowing role creation as long as the new role inherits from Cloudron's PG user for the app. But due to a lack of native restrictions in the CREATEROLE privilege and the lack of triggers for CREATE ROLE statements in PG, that seems nearly impossible to do.

So what I did instead is spending a good amount of time trying to massage logto's seed scripts (which always create 2 tenants, 1 for the app's default tenant and 1 admin tenant) to a place where logot is tricked into using the Cloudron provided DB user & roles.

I got the seeding working and the app will start. But currently you cannot acces the app as some internal lookup seems to be broken by my data manipulation.

I think there is a world where this could be made working by spending more time on manipulating the data just right. But in general it feels like this app in it's current state is not a great fit for Cloudron.

[walski]

One more thought: Does any other app spin up it's own Postgres instanace? Because that would also solve all the problems above. But my gut feeling was that this is considered a bad practive. But I'm happy to stand corrected.

[girish]

Right, we don't have any apps that run their own databases. In general, this won't work with backups/restore since one needs to take a proper dump of databases for it to be portable and consistent .

[robi]

@walski can it use any other DBs or even SQLite?

[walski]

@robi No, it's tied to PG at the moment. My guess is that there row-level access policies etc. make the app very tightly tied to Postgres.

[walski]

One way this could work is by working with Logto upstream to see if we can place a PR that changes the way they create roles and users to use a "security definer" function, basically a custom Postgres function that wraps aroung CREATE ROLE etc but can have more checks.

In this case the default function would be supplied by Logto like logto_create_role and would simply do a CREATE ROLE. Cloudron could also provide something like cloudron_create_role which could enforce that every create role is created as a subrole of the actual database user/role that Cloudron provisions for the user.

Then to bring it all together, the Cloudron Logto app would override the logto_create_role function and instead of doing a raw CREATE ROLE it would pass the execution to cloudron_create_role ...

That all said, it's quite a journey and I'd only reach out to the Logto folks if we can get some buy in that something like cloudron_create_role etc. could be part of a future Cloudron release. cc @girish

[robi]

@walski clever solution

I had thought of using a DB proxy that would translate the offending commands into the capabilities on the other side, even if it's a completely different DB/type.

And since the DB proxy can interface from one to many, one could have roles in MySQL, advanced meta operations in PG and data in Mongo or SQLite.
Each strength utilized.

Examples:

1. Metaproxy
2. SQLproxy
3. MaxScale
4. MySQL Router
5. Nginx & HAProxy
6. Tungsten Proxy

[walski]

Hmmm using ProxySQL might be pretty cool idea. I'll see if this leads anywhere. Thanks!