As I integrated more self-hosted services, authentication across them would get more and more messy. Having 10+ different user account/password pairs for each user VERY quickly ended up with me managing 150+ accounts by hand. Maintaining this became more like a part-time job than a chore after a while, and was taking away from the time I could have been spending deploying even more services! That’s where the need for an Identity Provider (from here, referred to as an IdP) was introduced.

Why an IdP?

My personal need for an identity provider was two-fold. First was to be able to create an identity for each user that would provision and manage accounts across each service for me. Second was to allow users to log into a single application that would handle the authentication for them across my local infrastructure. As an added bonus, Authentik lowers the attack surface on the infrastructure by essentially quarantining log-in attempts and handling them all itself.

Setting a set of credentials for each service for my less tech-savvy users was a headache to say the least, and getting them to use secure passwords was almost impossible for apps that didn’t enforce these rules themself. With Authentik I can avoid all of those issues, and have a single account/password pair for each user, along with password rules, MFA, and more if desired.

Why Authentik?

In my research, I found that IdPs are experiencing a bit of a renaissance if you will. Coinciding with the rise of home labs, there are many new options for self-hosted IdPs. Instead of the days of Active Directory and LDAP, we are seeing a lot of more modern solutions that integrate numerous authentication methods. Authelia, keycloak, oak, and finally, Authentik. After reading up on the options, Keycloak seemed the most mature, followed by Authentik, and finally, authelia and oak seem like the newest options worth considering that I’ve come across. Authelia seems really promising, they are currently working on a web ui, but the base of doing everything with config files means that it would integrate with nixos better. I felt that I wanted to see what the newer figures are doing, but also wasn’t quite confident in my ability to do everything via text. Authentik’s maturity over the newer options, and webui made it seem like a much more relaxed, and probably quicker, way to learn about these technologies.

Where it fits

In my last article I described a little bit about the network infrastructure I was building and maintaining. Namely, that I was using my VPS as a wireguard hub and connecting my home server to it. From there, I would forward my local subnet through the tunnel, allowing other users connected via wireguard to access my local DNS servers, which would forward requests to a reverse proxy on my VPS, allowing me to keep TLS in-tact. In between that reverse proxy and the services on my home server, is where Authentik would sit. The encryption provided by https connections is what allows us to forward sign-in credentials to Authentik.

VPN User -> VPS -> Local DNS -> VPS Reverse Proxy -> Local Authentik -> Local Service

Deploying Authentik

Deploying was simple, all I had to do was make a systemd service for it in nixos and enable it. After a little bit of poking around I learned that Authentik integrates with docker to run containers for it’s various services. It’s own reverse proxy, an LDAP server, and it’s own workers. I had to add the Authentik user to the docker group in order to give the daemon permissions to spin up containers and that was it.

Considerations

Now that Authentik was installed and running on my home server, I had to take the time to think about how I wanted it to function. There are a lot of ways to configure Authentik for different use-cases, and getting this wrong could mean security vulnerabilities. To access the SSO portal itself, I will put it behind the reverse proxy on the VPS and only allow RFC 1918 addresses, making it so only people on LAN or connected via the VPN can access it. From there, I will create a new group for each application, and add users to each group for the apps they will have access to.

Integrations

Now that Authentik is up and running, I have to integrate my services with it in order to have it provide authentication and user provisioning for each of them. The documentation for the integrations can be found here. The three authentication methods I have used so far are OpenID/OAuth2, LDAP, and basic proxy authentication. OAuth2 is the cleanest and preferred method, while basic proxy auth is the simplest. OAuth2 is useful because it stores sessions in cookies, allowing for log-ins to persist. Proxy auth is useful because it can intercept the requests before they reach the service, allowing you to authenticate apps that don’t have native authentication support.

Insights

This project taught me a lot about authentication methods, flows, and consent types. I also was able to bring my understanding of permissions a layer deeper to due manually provisioning and configuring user access models. Most importantly, I got hands on experience orchestrating a system with many moving parts in order to accomplish this goal.

Improvements

With Authentik, on-boarding users into my network is a lot easier. Before the process was to have them connect to the VPN, then navigate to the correct URL, then remember separate passwords for each account (and, consequently, demanding an admin make user accounts for each service). Now, user accounts are created for each service automatically after being created in Authentik. Moving forward, my plan is to deploy a mail server using mailcow. This will cut out the need for them to navigate to the correct url, and for me to create passwords for their account to give to them. Instead, once connected, they will be able to check their personal e-mail for an invitation into Authentik.