I recently went down this road for my home lab and went with Authelia
Keycloak works, but it's a behemoth and still needs further services to work with traefik forward auth.
Authelia works great, you don't get a UI to edit users, and it's not a two-way sync between a backing LDAP server, but the fact that it can be configured with a static file + environment variables makes it a great fit for a lot of cases. If you're just looking to add auth to some services, and SSO to those that can work with it, I'd suggest starting with Authelia.
If you are looking for SSO + easy configuration + an admin UI (which admittedly has a mid 2000s UX look and feel), you should check out FusionAuth. It's free to download and run yourself[0], docker friendly[1], has a variety of configuration choices[2] (including terraform[3] to manage your OIDC/other settings).
Worth noting that it is free to use, but not open source[4].
I can only speak from my perspective as an employee, not the whole company. It is something I've thought about. I will also ask the CEO/founder or other leaders to weigh in.
Many devs care about open source when they are evaluating a solution, but many really want "free as in beer". They want to try a product without getting out the credit card or engaging with sales. We cater to the latter category, which wants to understand the product quality without talking to any sales people.
Some of these folks use our community product for their production needs, which is perfectly fine. We have people running FusionAuth in production with 1000s of tenants or 10000+ applications. (I always say they "pay" us by filing bug reports, giving feedback and voting on feature requests.)
But some decide they want to pay us for hosting, support or advanced features. Those choices help us build a business.
Devs, and especially buyers, are interested in sustainability of a product they are going to integrate into their system. An auth provider isn't a javascript widget that you can easily drop in or remove from your system. It embeds in your system, even if you stick to a standard like OIDC, and is difficult to switch from, especially at scale. You want to be sure the company and product is going to stick around. (If you want to make sure you can run the product even if everyone at FusionAuth wins the lottery, we do offer source code escrow for a price, but haven't had anyone take us up on it.)
FusionAuth is a profitable company (we did recently raise a round to accelerate growth, you can read more about that here [0]). Open source companies often have a hard time meeting the profit goals of the market or investors. This is a known issue and often results in relicensing or changing the rules, as we've seen with Hashicorp[1] and Elastic[2]. This switcheroo can cause issues, confusion, and ill-will; FusionAuth's licensing avoids that.
FusionAuth also develops in the open[3]. This open development process gives us another common benefit people get from OSS--community feedback.
Also, I don't want to throw shade at Ory and Zitadel, since I have no idea about their finances (apart from a brief look at Crunchbase, which shows they've raised 22.5M[4] and 2.5M[5] respectively). I hope they're building sustainable businesses, but selling closed source software is a sure route to a profitable business that has built many big companies (including in the auth space, such as Okta or Auth0). Again, this is not FUD (or at least I don't intend it to be!), just an honest assessment at the difficulties of making money in open source dev tools [6].
We also compete on features, support and documentation. Again, I can't speak to Ory or Zitadel; they look nice, but I haven't built anything with them, so it is hard for me to know how good they are. I do know that we have had many clients appreciate of those aspects of our product.
To sum up:
* FusionAuth has a free option, which helps reduce friction and gives some of the benefits of OSS. The open process and escrow also give some of the benefits of OSS.
* Some devs and buyers care about business sustainability, especially when integrating a tool deeply into their application. FusionAuth will never have to worry about relicensing a version because AWS is eating our SaaS revenue stream, for example.
* We offer great support, documentation and intricate auth features at a reasonable price.
>> It embeds in your system, even if you stick to a standard like OIDC, and is difficult to switch from, especially at scale.
This is precisely why a real, Open Source solution should be a top priority feature for anyone evaluating software like this. We have seen closed source solutions, time and time again, "realign" their business by dropping features, or even entire, free plans. In some cases, closed source software has been removed from the market all together when the company gets bought out. Changes in pricing plans leads to a worse fit for customers... etc. At least when Hashicorp and Elastic abandoned Open Source, the community had the option to say "yeah, good luck, thanks for the good times, but no thanks on your new direction" and fork the product to continue maintaining it. When a closed source products owners decide to "shift gears" on the product line up, customers are left between a rock and a hard place. Maybe if there were no Open Source options, but fortunately, there are several in the auth space.
I've been thinking lately how important it is that software be not only open source, but simple enough to be forkable. The fact that Keycloak is open source almost seems irrelevant given how massive the codebase is.
Thanks for the detailed answer. If people are already taking advantage of your free offering, how would it be different if you released the source? If you're worried about another company piggybacking off your work to start a competitor, why not use one of these newfangled non-compete licenses? That still gives users the security of being able to for the project internally if you go under.
Sorry, on re-read, this sounds kinda abrupt. My bad.
I think at the end this is a business decision. The executive team has considered options and decided that closed source is the right path for the company.
How do I integrate this with a reverse proxy like Caddy and their forward_auth directive? I want to secure my apps on the proxy layer, not the app layer.
You'd have FusionAuth issue the tokens through an authentication event (typically the authorization code grant for interactive sessions). Lots of flows with sequence diagrams outlined here [0].
Then store the tokens on the client. For browsers dealing with first party apps (everything under the same domain) we recommend cookie storage of these tokens [1].
Then have Caddy examine the tokens provided by the browser. Here's an example Caddy config I put together for a workshop [2].
Finally, depending on your security posture, you might want to verify tokens both in app and at the proxy.
Hey one of the Authelia developers here. Authelia works out of the box with Caddy's forward auth directive. In fact I helped Caddy develop and test the feature to ensure it had feature parity with an existing implementation/spec.
You have very granular options to customize the experience allowing multiple sites to have the same or different rules, which can alter the authentication requirements based on remote ip, users, groups, paths, domains, etc.
If you look for 2FA with otp, email, sms and also passkeys foe self-hosting, then give zitadel a spin. All features are included in the open source version. Should also work nicely with docker compose + nginx. In case you have issues, join the chat.
https://github.com/zitadel/zitadel
I have Authelia running for 2+ years already. I configured it with LDAP using "LLDAP" [0], a lightweight LDAP implementation. I then use Caddy as a reverse proxy and integrate it [1] with Authelia. This works great. I have solid 2FA for all my services and I feel my self-hosted applications are secure enough to be accessed without VPN. My only concern is that Authelia hasn't had a new release for more than a year, which raises security concerns.
> My only concern is that Authelia hasn't had a new release for more than a year, which raises security concerns.
I'm a bit concerned about that too. When setting it up, I found a lot of their docs on github mentioned they have `template` and `expand-env` "configuration filters", then it took me entirely too long to realize that while the 4.38 pre-release notes, posted in January 2023, say it's "just around the corner", it's still being worked on.
Having said that, there still seems to be somewhat active development. It may just be one person at this point.
It's me and two others though I'm definitely the most active. We put a lot of effort into security best practices and one of my co-developers is currently reviewing the 4.38.0 release. It's a fairly major release with a lot of important code paths that have been improved for the future.
Hey one of the Authelia developers here. We're very actively working on a very large release (it's just going through the peer review process and it should be good to go) and we currently have a pre-release for users to dive into.
I can understand the security concerns but we are regularly taking measures to ensure no zero-day vulnerabilities exist, there are no known vulnerabilities with Authelia at the present time either directly or via the code-paths of dependencies we actually use.
If you'd like a newer build of the pre-release they are available. Feel free to reach out on GitHub Discussions (may not see it here but see how we go).
I also went down this road recently, and discovered caddy-security, but I have security concerns [0]. Software always has vulnerabilities, but this was enough to scare me off. Something like keycloak or authentia seems more tested and secure.
Authelia has a very unique advantage of its small footprint, which is something that neither Keycloak nor authentik (which I work for as a disclaimer) can really fit into. It’s a very good usecase for a homelab environment and if you don’t need/want features of the “bigger” solutions!
Tangential, but are there any alternatives to LDAP today? I googled around and found nothing. Simpler schema, JSON, http, etc. I can't believe nobody has attempted to recreate it when people have for basically everything else. AFAICT the only real other standard is Active Directory.
And secondly, is there a standard or protocol for offloading access control? I see Authelia allows you to contol access by url patterns, but I'd expect e.g. a fileserver to instead reach out to the LDAP server and check permissions based on the authenticated user id and keys in the database. This seems like the opposite of oauth2 which is for a server getting access itself to a 3rd party service.
Really? It prefers a database, sure, but you can also store on disk. And you can also configure the main user with env variables.
It starts within <3s on my toy server since they refractored it a few years ago and uses less then 100mb ram (again, toy server, not many users etc)
Idk, calling that a behemoth is kinda a stretch at that point...?
The thing that annoys me about keycloak is how they decided to ship it. I really don't want to maintain a CI Pipeline to deploy it .. but you're kinda forced to with how they've designed their docker image.
Not an issue for enterprise as they're gonna be doing that anyway, but annoying for home servers
Behemoth may be a bit of a stretch, but the container is 20x the size of authelia, it's minimum recommendations are 512mb ram, and 1g of disk space. Compared to Authelia, which is using 30mb of ram and 500k disk space, yeah it's big.
Not to mention, only the admin user being configurable via environment variables isn't enough. With Authelia, I can share my homelab setup and with a couple of environment variable changes, people can have SSO integrated. There's no need to write guides or grab screenshots to help them get set up.
have you looked at the codebase? it's been a while but I was implementing Keycloak a few years ago and it was shocking how big the codebase is and how difficult it is to change things to add what felt like basic functionality. making plugins didn't seem like a viable option either.
oh not to mention the statefulnes of it, it was almost impossible to destroy and re create an instance from scratch without a bunch of manual point and click via the UI.
It is built on a plugin architecture, so plugins are certainly a viable option and this is documented in more detail here[0]. In general I have found the Keycloak docs thorough and well-written. When I operated Keycloak I built a few plugins to solve specific needs/assumptions we had around IdP when migrating to Keycloak from a bespoke solution.
Re: your second point, the docs also describe this in detail[1]. Having the realm data exist in a simple form that can be exported/imported was very useful. However, I would have liked if they thought more about how to do live backup/restore; perhaps that is easier now than it was at the time.
A lot of problems, actually, and most people don't have many of them. If you just want an OIDC server in front of your self-hosted apps you can solve that with a much simpler and faster tool.
The docs can say whatever it wants, there were large parts of our configuration that wasn't included in an export, so we couldn't automate provisioning.
Had a similar experience and even filed a couple of bugs back then. I don't know the current state but back then it felt like having something that looked like halfway modern Java but still carried around large amounts of old school JEE cruft. Probably was the migration to quarkus though. So it probably got better?
Interesting... I had the exact opposite impression. The codebase is big but very easy to understand and their SPIs[1] enable to customise Keycloak's behaviour quite easily.
For the statefulness using terraform[2] solves the problem for me.
> 2024-02-11 17:15:35,764 INFO [io.quarkus] (Shutdown thread) Keycloak stopped in 0.064s
> 2024-02-11 17:15:37,754 INFO [org.keycloak.common.Profile] (main) Preview feature enabled: token_exchange
...
> 2024-02-11 17:15:44,694 INFO [org.infinispan.CLUSTER] (jgroups-8,a4c127cdee40-48683) ISPN100000: Node 72d48695e84c-46513 joined the cluster
so 7 seconds altogether on that restart, though a lot of that time is spend waiting for other nodes before it bootstraps the cluster.
(its single node as its a toy server, as i said before)
Keycloak works, but it's a behemoth and still needs further services to work with traefik forward auth.
Authelia works great, you don't get a UI to edit users, and it's not a two-way sync between a backing LDAP server, but the fact that it can be configured with a static file + environment variables makes it a great fit for a lot of cases. If you're just looking to add auth to some services, and SSO to those that can work with it, I'd suggest starting with Authelia.