A new open-source Single Sign-On (SSO) provider designed to simplify user and access management.
Features:
- 🙋♂️ User Management
- 🌐 OpenID Connect (OIDC) Provider
- 🔀 Proxy ForwardAuth Domains
- 📧 User Registration and Invitations
- 🔑 Passkey Support
- 🔐 Secure Password Reset with Email Verification
- 🎨 Custom Branding Options
Screenshot of the login portal:
I do agree. I have been thinking about adding a SQLite option which should be somewhat easy since knex (the database package that VoidAuth uses) supports it. Before releasing that I would want to create some way to migrate your data from one database type to another. If you want to use VoidAuth feel free to make an issue for this!
Having run minor projects using PocketBase before and also seen what PocketBase itself can do and SQLite configured correctly in general, It’s great. I’ve gotten to be a big fan of it by the years and gladly opt for it over the bigger ones.
If this project got SQLite support it would be a great replacement for my own setup which requires about 3 or 4 accounts. Currently using a proprietary solution and been looking into moving to Authentik but it’s a bit too heavy resource wise for my current servers.
I will make an issue for adding SQLite support, it has been on my mind for the same reasons. I would say don’t let the Postgres requirement stop you from trying it out. Modern hardware really doesn’t mind having multiple containerized postgresdb instances running, it can be very lightweight when idle.
Tbo, not using a tool because it only uses postgres sounds strange to me.
It does mean a form of provider lock-in, which is or can be its own issue. Also, while PostgreSQL is one of the best database engines out there among the FOSS stuff, it is verifiably and vastly overblown for stuff like “store a name and a email”, and I at least am not aware of any sort of “Postgres Lite” engines else I’d be using them at work.
How does it lock you in? You, the admin, has full control over postgres. Sqlite has no security features. Does it store passwords? Sqlite also locks the database which is usually OK if there are no concurrent jobs. But for such services it sounds like a bad idea to use sqlite. (I am no server/app dev)
Sqlite shouldn’t lock for read, so unless you are writing something at each access, you can have thousands of concurrent reads. The Sqlite website spells this out, and lists its own self as the proof.
This would mean you could not write logs to the database, you’d have to do it the unixy way and put logs in a text file.
Yeah, I use Authentik currently and the main reason is simplicity of having it with LDAP. But I’ve considered running something else backed by FreeIPA to get more compatibility for LDAP. I feel like I have to fight to get something to work with it.
But it has some high overhead for sure.