What it is
Authentik is an open-source identity provider. It holds the user accounts, groups and sign-in policies, and every other application trusts it to say who someone is. When you open an app here, the app does not check your password. It sends you to Authentik, Authentik checks you once, and you come back signed in.
It speaks the three protocols that matter. OIDC for modern web apps, SAML for the enterprise software that still expects it, and LDAP for the older tools that only know how to ask a directory. For applications that speak none of those, it can sit in front of them as an authenticating proxy, so nobody reaches the app without passing through the login first.
Why I run it instead of the SaaS alternative
Okta, Microsoft Entra ID and Google's identity services are good products. For a company already living inside Microsoft 365 or Google Workspace, with a team to manage it, the hosted option is often the right call. I say so when it is.
My reasons for running my own are specific. First, the identity provider is the key to everything else, and I want that key on infrastructure I control. Second, per-user pricing punishes exactly the thing I want to do, which is put every small tool behind the same login, including the service accounts and test users. Third, the forward-proxy feature lets me protect applications that have no login of their own, which hosted providers handle less directly. And fourth, I want to be able to read the logs and change a policy without opening a support ticket.
The cost is that I am the one who keeps it running. If the identity provider is down, nobody signs in to anything. That is a real trade, and it is why it is monitored more closely than anything else here.
How it is set up here
- One container stack, one database. Authentik runs in its own containers on the same server as everything else, with its own database that is dumped nightly and pulled off the server.
- Behind the single edge. Like every other service, it sits behind the one nginx edge that handles certificates and routing. Nothing talks to it directly.
- Apps that speak a protocol use it. Applications that support OIDC or SAML are registered as clients and send users to Authentik to sign in.
- Apps that do not get a guard. For anything without SSO, the edge asks Authentik whether the visitor is signed in before passing the request through. If not, they go to the login page first.
- Monitored like it matters. Uptime Kuma checks that the login page actually renders, not just that something answered, and the daily health check covers it too.
What it replaces
- A separate username and password for each application, and the spreadsheet of who has access to what.
- Hosted identity subscriptions charged per user per month.
- Basic-auth prompts and shared passwords in front of internal tools.
What it costs to run is server capacity and attention: updates applied deliberately, the database backed up, and someone who understands what each policy does. It is not free, but the cost does not grow every time you add a person or an app.
What I would do for a client
Start with the audit: every application, how people sign in to it today, and who still has access after they have left. That list is usually the most alarming page of the report.
Then decide where identity should live. If you already pay for Entra ID or Google Workspace, the honest answer is often to make that the source of truth and connect everything to it properly. If you do not, or if you need to protect tools those services cannot reach, Authentik is a strong option. Either way the work is the same shape: one directory, one login, groups that map to real roles, a proxy in front of the stragglers, and an offboarding step that removes access everywhere at once.
Questions people ask
Is self-hosted identity less secure than a big vendor?
It depends entirely on who runs it. A well-maintained Authentik with sensible policies is sound. A neglected one is a liability. If nobody on your side will own it, a hosted provider is the safer choice and I will tell you that.
Can it do multi-factor authentication?
Yes. Authenticator apps, security keys and passkeys are all supported, and policies can require them for some groups or applications and not others.
What about the old app that only has its own login form?
That is what the forward-auth proxy is for. The app keeps working as it did, but nobody can reach it without signing in through the identity provider first.
What happens if it goes down?
Sessions already established keep working for a while, but new sign-ins fail. That is why it is monitored closely, backed up nightly, and why a break-glass route for administrators is part of any setup I build.