Learn Authentik - Pre-Requisites Skills & Environment Setup

#Introduction

Welcome to the Learning Authentik series! This series will take you from zero to building a solid identity infrastructure with Authentik — a modern, open-source identity provider written in Python with a UI-first approach. 31 episodes in total: starting with prerequisites & environment setup, history & background, architecture & core concepts, installation, understanding flows & stages, users, groups & attributes, policies, authentication stages & MFA, OAuth2/OIDC provider setup, property mappings & claims, integrating applications with OIDC, proxy provider & forward auth (Traefik, NGINX, Caddy), SAML provider, OAuth sources, LDAP & Active Directory, LDAP outpost, reputation & threat detection, branding & theming, API & automation, events & auditing, high availability, Kubernetes, monitoring, backup & disaster recovery, security hardening, troubleshooting, migrating from another identity provider, and a production checklist.

Authentik solves one classic problem of self-hosting and enterprise: many applications, many login systems. It unifies authentication behind a single door — while also serving as an Identity Provider (IdP) that speaks modern protocols like OAuth2, OIDC, and SAML, as well as legacy protocols like LDAP.

Episode 0 is a roadmap. Before we dive deeper into Authentik, we make sure three foundations are in place: (1) the core skills you must master, (2) the software and hardware you need to prepare, and (3) the lab topology used throughout the series. Don't skip ahead — Authentik sits at the center of your identity traffic, so a shaky foundation will be felt in the episodes to come. Let's get started.

#Core Skills You Must Master

Authentik is not an install-and-forget application. It speaks identity protocols, reads HTTP requests, and runs on containers. You don't need to be a security expert, but the concepts below must be genuinely understood — not just memorized as terms.

#Authentication vs Authorization

Two terms that are often mixed up, even though the difference shapes the design of your entire system:

• Authentication — proves who you are. The question is: "Are you really this user?" Usually via username + password or another factor.
• Authorization — decides what you are allowed to do once your identity is proven. The question is: "Is this user allowed to open the admin dashboard?"

To use an analogy: authentication is the ID check at the entrance; authorization is the rule about which floors you may enter after your ID has been checked. Authentik handles both: it authenticates through flows, then authorizes through policies.

#OAuth2 and OIDC

OAuth2 is an authorization framework that lets applications get access on behalf of a user without ever seeing the user's password. OpenID Connect (OIDC) is an identity layer on top of OAuth2 that adds a JWT-formatted id_token — so applications also know who the user is, not just what they may access. OIDC is the most common protocol you'll integrate with Authentik in phase 3 of this series.

Key concepts you must know: client (the application requesting access), authorization code (a temporary code), access token (the access ticket), scope (the permission scope like openid, profile, email), and redirect URI (where to return after login). Don't worry about going deeper now — episodes 8 through 10 will dissect them line by line.

#SAML Fundamentals

SAML is an older SSO protocol (XML-based) that is still very dominant in enterprise applications. The core concept: the Identity Provider (IdP) issues an assertion — a signed XML document containing the user's identity — and the Service Provider (SP) accepts it. Key terms: ACS URL (where the assertion is delivered), Entity ID, and metadata (an XML block describing an IdP or SP configuration). SAML isn't required to follow this series, but it helps — episodes 14 and 15 cover it.

#Docker and Container Concepts

Almost every episode in this series deploys Authentik along with PostgreSQL and Redis via Docker Compose. You must be comfortable with the basic docker compose up -d, docker compose down, docker ps, and docker logs commands, plus the concepts of volumes for persistent data and networks between containers. If you still have doubts, study the Learning Docker series first — Authentik doesn't require advanced Docker skills, but you must understand what images, containers, and volumes are.

#YAML

All configuration and compose files are written in YAML. YAML is sensitive to spaces and indentation — "looks the same" doesn't mean "is the same". The most common mistake isn't in the logic but in indentation that's off by one space. Master the three basic structures: key-value, lists, and nested mappings. That's enough to follow the entire series.

#HTTP and JWT

Authentik is an HTTP server. You'll deal with redirects (HTTP 302) when directing users to the login page, cookies for sessions, and headers that carry identity (for example X-Authentik-Username). Meanwhile, JSON Web Token (JWT) is a signed, JSON-based token format — it's the foundation of OIDC access tokens and ID tokens. You don't need to write a JWT parser, but you must understand its three-part structure: header, payload, and signature.

#Basic Networking: DNS, Ports, and Reverse Proxy

Authentik relies on a domain. In this series we'll use auth.example.com (replace with your domain), pointed via DNS to your server, and Authentik listens on port 9000 by default. You should also understand the reverse proxy — a server in front of applications that forwards client requests to the right application, like a building receptionist directing guests to the correct floor. NGINX, Traefik, and Caddy are popular examples, and Authentik is designed to sit behind such a proxy. Phase 4 of this series integrates Authentik with Traefik, NGINX, and Caddy.

#Software and Tools to Prepare

Set up the following tools before moving on to episode 3:

#Minimum Hardware Specifications

Authentik is written in Python and runs as a full web server with a database and cache behind it. It's heavier than a lightweight auth proxy, so prepare:

• RAM: 2 GB minimum, 4 GB or more recommended (server, worker, PostgreSQL, and Redis share memory).
• Storage: 10 GB of free space (images, database volumes, media, and logs).
• CPU: dual-core minimum.
• OS: a Linux server (Debian, Ubuntu, Rocky) is highly recommended — just like the production environment.
• Network: a stable connection; a public IP isn't required — a subdomain can be pointed at your local network.

#Official Authentik Images

Authentik is distributed as a Docker image on the GitHub Container Registry (GHCR):

• ghcr.io/goauthentik/server — the server process (web UI + API).
• ghcr.io/goauthentik/server with command: worker — the worker process (async tasks like sync and email). One image, two roles.
• ghcr.io/goauthentik/proxy — the proxy outpost image, the component that sits in front of applications for forward auth (covered in phase 4).

docker pull ghcr.io/goauthentik/server:latest
docker pull ghcr.io/goauthentik/proxy:latest

docker --version
docker compose version

#Designing the Lab Topology

Before closing this episode, let's design the topology used throughout the series. One example.com domain (replace with your own domain) hosts:

                  +---------------------+
Browser  ------->  |  Reverse Proxy      |   (NGINX/Traefik/Caddy, port 443)
                  |  auth.example.com    |
                  +----------+----------+
                             |
                             v
                 +----------/----------+
                 |   Authentik         |
                 |  server + worker    |   (port 9000 internal)
                 |  flows & stages     |
                 +--+---------+--------+
                    |         |
                    v         v
              +---------+  +--------+
              |Postgres |  | Redis  |
              |  data   |  | cache  |
              +---------+  +--------+
 
Applications being integrated (SSO / forward auth targets):
  grafana.example.com   portainer.example.com   nextcloud.example.com

In short, the flow is: browser → reverse proxy → Authentik executes the authentication flow → a token/session is issued → the application receives the user's identity. Episode 2 dissects this architecture in detail.

#Closing

In this episode 0 you mapped out three foundations: core skills (authentication vs authorization, OAuth2 & OIDC, SAML, Docker, YAML, HTTP & JWT, and networking), software & hardware (Docker Compose, PostgreSQL, Redis, reverse proxy, editor, Postman, OpenSSL, plus a minimum server spec of 2 GB RAM), and the lab topology using the official ghcr.io/goauthentik/server and ghcr.io/goauthentik/proxy images.

Points to take away:

• Authentication proves who the user is; authorization decides access rights — Authentik handles both.
• The protocols you'll encounter: OIDC (modern), SAML (enterprise), and LDAP (legacy) — all supported by Authentik.
• Authentik is a full HTTP server with a database and cache — it needs more RAM than a lightweight auth proxy.
• The entire lab can run on a single machine as containers.
• The official images live on GHCR, not Docker Hub.

The Learning Authentik series has 31 episodes that build on one another. Episode 0 is the first brick. In episode 1, we step back for a moment to answer the defining question: the history, background, and why you need Authentik — from the problem of "many applications, many login doors" to an honest comparison with Keycloak, Authelia, and Zitadel. See you in episode 1, and good luck preparing your identity lab!