Learn Authentik - History, Background & Why You Need Authentik

#Introduction

After ensuring in episode 0 that the environment is ready — core identity protocol skills, Docker Compose installed, and the lab topology designed — in this episode we step back for a moment to answer the most defining question: why do we need Authentik?

This isn't just historical trivia. Understanding the background answers three practical questions: (1) what exactly is wrong with the "many applications, many login systems" situation we've long accepted as normal, (2) why existing solutions — Okta, Keycloak, Authelia — don't always fit your needs, and (3) when Authentik is the right choice and when it isn't. Just like understanding the history of a technology, understanding the background lets you not only install it, but also know why it exists.

#The Problem: Many Applications, Many Doors

Imagine your house has ten doors, and each door has a different key. The same guest has to carry ten different keys, and you have to remember ten different rules about who may enter through which door. That's the state of most self-hosted servers and offices:

1. Password fatigue. One person remembers passwords for Grafana, Nextcloud, Portainer, Jellyfin, and dozens of other applications. The result: passwords get reused, written on sticky notes, or chosen to be the easiest to guess.
2. Inconsistent policies. One application enforces strong passwords and MFA, another accepts 123456. There's no shared standard.
3. No single audit point. If an account is compromised, there's no single place to review all login activity — each application logs its own events, in its own format.
4. Security depends on the weakest application. A single application without MFA support becomes the weakest entry point to the entire network.

Authentik was born as an answer to this chaos: one door, one policy, one audit trail, and one place to enforce MFA.

#The Identity Provider Landscape

#Commercial Solutions: Okta, Auth0, Azure AD

Okta, Auth0, and Microsoft Entra ID (formerly Azure AD) dominate the Identity-as-a-Service market. Their strengths: vendor-managed, guaranteed SLAs, broad enterprise integrations, and a full feature set. The pricing follows — typically per user per month, and costs grow with features (MFA, passwordless, lifecycle management) and user volume. For large companies, this is reasonable. For a homelab, a personal VPS, or a small startup, recurring monthly costs often feel disproportionate.

#Open Source Alternatives: Keycloak and Authentik

On the open source side, the two biggest names are Keycloak (backed by Red Hat, written in Java) and Authentik (the goauthentik project, written in Python). Both can be self-hosted at the cost of a server alone. The differences determine your choice, and we'll break them down in the comparison section.

#Self-Hosted vs Cloud-Hosted

• Cloud-hosted wins on convenience: no need to maintain servers, upgrades, or backups. You pay for that.
• Self-hosted wins on control and cost: identity data stays on your server, there's no vendor lock-in, and the cost is just electricity and maintenance time.

For this series, we focus on self-hosting via Docker Compose — the most common pattern in the Authentik ecosystem and the easiest to practice.

#Cost Considerations

In broad strokes: commercial solutions can cost hundreds of millions of rupiah per year for hundreds of users, while a self-hosted Authentik on a mid-tier VPS can be said to be "free" beyond server cost and time. But remember, self-hosting is not zero-cost — there are maintenance costs, upgrades, and risk if misconfigured. The "commercial vs open source" decision is a business decision, not just a technical preference.

#The Birth of Authentik

Authentik is developed by the goauthentik project and started to become widely known in the early 2020s. It was designed from the ground up as a modern identity provider for contemporary applications — not an adaptation of an old system — and is distributed as Docker images like ghcr.io/goauthentik/server and ghcr.io/goauthentik/proxy. Some of its design characteristics:

• Python-based — written in Python with a web framework, easy for the large Python community to understand and contribute to.
• Cloud-native — distributed as Docker images, designed for container deployment from day one, not after a "containerization" process.
• UI-first — almost all configuration happens through a web interface, not hand-written configuration files. This is the most striking difference compared to Keycloak.
• Flow-based — authentication flows are built from small blocks called stages assembled into flows. This flexibility isn't available in simple auth proxies.
• License — open source under the MIT license until release 2023.8, then switched to BUSL (Business Source License). The source code remains open, with certain commercial restrictions after an embargo period.

2021+    The goauthentik project gains recognition as a modern open-source IdP
2023.8   License changes from MIT to BUSL (Business Source License)
now      Actively developed, large community, complete documentation, Docker-first

#The Philosophy: Flows & Stages as Building Blocks

The core of Authentik's strength lies in a single idea: every authentication flow is built from small, composable blocks. A stage is a single step (for example "ask for username", "ask for password", "show consent"), and a flow is a sequence of stages serving a single purpose (for example "login", "register", "reset password"). Like LEGO: with a few dozen stage types, you can assemble a simple login flow or a complex enterprise onboarding flow. We'll cover this thoroughly in episode 4.

#Key Authentik Features

• Complete provider set — OAuth2/OIDC, SAML, and LDAP providers in one product; plus SCIM for provisioning.
• Proxy provider (forward auth) — Authentik can sit in front of applications via a reverse proxy and inject identity via headers — a feature usually only found in dedicated auth proxies.
• Outposts — remote components (proxy, LDAP) that can be deployed separately from the core server for scale and network segmentation.
• Policies — conditional logic (including Python expressions) to control access, for example "only the admin group during working hours".
• MFA — TOTP, WebAuthn/FIDO2, static tokens, and more.
• Social login — OAuth sources for Google, GitHub, Discord, and more.
• Clean, UI-first design — a modern, easy-to-navigate interface.
• Docker-first deployment — a single compose file to get everything running.

#Authentik vs the Alternatives

#Authentik vs Keycloak

This is the most frequently asked comparison. Keycloak is the veteran — the most complete enterprise feature set and the most widely used in companies. But its configuration is heavy: many menus, the realm concept, and much of it set through dense forms. Authentik answers with a different approach: a clean UI, the expressive flows concept, and simple Docker deployment. Written in Python vs Java, Authentik also feels lighter in day-to-day operations. For new self-hosted projects, many engineers choose Authentik for a more humane configuration experience.

#Authentik vs Authelia

Authelia is an auth proxy specialist: it sits in front of applications and handles forward authentication very well — lightweight, a single Go binary, and file-based configuration. But it isn't a full identity provider: its OIDC is limited, and there's no SAML provider or LDAP outpost. Authentik is a full IdP that also has forward auth capabilities via the proxy provider. If you only need to protect a few applications with SSO + MFA and want something light, Authelia is enough. If you need an identity platform that can be integrated as an OIDC/SAML IdP into other applications, Authentik is far more complete.

#Authentik vs Zitadel

Zitadel is a modern Go-based competitor with a cloud-first design and attractive features like an action API and human-to-machine access. It's strong in cloud and Kubernetes ecosystems. Authentik's advantages here: the outpost ecosystem that makes deployment outside a cluster easy (standalone Docker, VPS, bare metal), more practice-oriented documentation, and a very active self-hosting community. Both are capable; the choice often comes down to deployment preference and closeness to the classic Docker ecosystem.

#When to Choose Authentik

• Self-hosted SSO — unify the login of all applications on your home server or VPS.
• Application authentication — act as an OIDC/SAML IdP for modern applications.
• Forward auth for reverse proxies — protect applications without a login system (Grafana, Portainer, etc.) via Traefik, NGINX, or Caddy.
• LDAP outpost for legacy apps — old applications that only understand LDAP can be authenticated against Authentik users.
• Social login aggregation — a single portal that accepts Google, GitHub, and Discord logins along with local accounts.
• Employee/customer identity management — SMBs that need identity management without enterprise IdP license costs.

#Closing

In this episode 1, we understood the root problem Authentik solves: the chaos of many login doors — password fatigue, inconsistent policies, and security that depends on the weakest application. We explored the identity provider landscape from commercial solutions (Okta, Auth0, Azure AD) to open source alternatives, saw the birth of Authentik by the goauthentik project — Python-based, cloud-native, UI-first, MIT-licensed until 2023.8 then BUSL — and compared it honestly with Keycloak, Authelia, and Zitadel.

Key takeaways:

• The real problem is many applications with many unmanaged login systems.
• Authentik is a modern all-in-one IdP: OIDC, SAML, LDAP, and forward auth in one product.
• vs Keycloak: cleaner and UI-first; vs Authelia: far more complete; vs Zitadel: friendlier to the Docker and outpost ecosystem.
• For self-hosting and SMBs, Authentik wins on the balance of features and ease of use.

In episode 2, we'll dissect Authentik's architecture and core concepts: how the server, worker, PostgreSQL, Redis, and outposts work together, what tenants, applications, providers, flows, stages, and policies are, and the journey of a single request from browser to returning with a token. See you in episode 2!