I love the simplicity of this, I really do, but I don't consider this SSO. It may be if you're a single user, but even then, many things I'm hosting have their own authentication layer and allow offloading only to some oidc-/oauth or ldap-provider.
this post was submitted on 25 Apr 2025
78 points (95.3% liked)
Selfhosted
46372 readers
724 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 2 years ago
MODERATORS
In the simplest form it might be SSO. It does support multiple users and if you look for instance at the filebrowser it’s very possible to pass the username. But yes, this is very simple, very crude and exactly what a lot of people need.
I'm torn between this being fucking genius, and a terrible idea all at once.
EDIT: Requires ngx_http_auth_request_module. * Caddy4lyfe. *
Well, me too. But frankly OpenIAM (24GB of RAM as a requirement) Keycloak, Authelia do too much, require too much and aren't suitable at all for SBCs and small scale stuff.
Edit: This is targeted at people that run nginx as a standalone server or proxy.
I respect it.
I didn't test, but should be possible with forward_auth (https://caddyserver.com/docs/caddyfile/directives/forward_auth)
Nice! I'll give it a try.
If you manage to make it worth with Caddy can you share your config? I can add it to the readme or something. Thanks.
For sure. I'm likely gonna take a look at it this weekend.
I have been constantly asking myself why there isn't something like this, and just wondering if maybe I was missing something about the seeming immense complexity of doing this on a small scale.
Now there is something like this.
I don't love PHP, but I also don't love having dozens of separate passwords, keys, certificates and other nonsense to keep track of like I'm doing now. I don't mind using PHP to get around that if I can.
Well, it isn’t pretty, but gets the job done.
The thing with PHP in this case is that I was already serving a ton of simple websites / small apps like freshrss that use PHP and by making this tool in PHP it means I don’t need yet another process running and wasting resources, can just re-use the existing php-fpm for this.
For what’s worth PHP is better than it looks, and my implementation is very crude, but also small and auditable and contained to a single file. :)
Fun little project but I think auth_basic would be perfectly fine instead.
Hmm… some people are going to say that basic auth would be insecure, I’m not going to be there because in this particular case it’s about the same thing.
However, this might be easier to configure and manage permissions than basic auth. Also this works cross-domain and basic auth will require full re-auth for every domain. Another obvious advantage is that at some point I plan to integrate 2FA.
I feel like committing secrets to a config file instead of .env is a terrible idea. Thats being said this is really useful I'm sure.
The entire point of .env files are to separate secrets from code. Its specifically the usage for which they were created.
Yes?
Are we misunderstanding each other?
We are. I read I feel like committing secrets to a config file instead of .env is a terrible idea. as I feel like committing secrets to a .env is a terrible idea..
Muh bad.
All good brother :)
I get the point, but don’t forget those “secrets” are bcrypt hashes. Not really reversible.
The issue isn't that. The issue is its a config ~~folder~~ file and a lot of people back their configs up to things like github.
You can backup the entire file then. I get your point, but it also seems like you’re referring to some container-based approach where you would place this inside a container and then mount the config file to some path. While some people might like that approach, that kind of goes against the original idea here, I didn’t want to run yet another instance of nginx for auth, nor another php-fpm - the ideia was simply to use this on a low power device , no containers, no overhead of duplicate webservers and PHP, just a single nginx running a couple of apps on the same php-fpm alongside this.
I think youre misunderstanding my point but thats okay. Its not for me but as a thing itself its really impressive and you should be proud to have written it. I'm sure others will find great use in it :)
I can split the config to another file, not really a big deal. :)