Learn Authentik - Architecture & Core Concepts

#Introduction

After understanding in episode 1 why Authentik is needed — one entry point for many applications — in this episode we dissect how Authentik works behind the scenes. This is the most important episode before touching configuration: without the architecture, every button in the Authentik UI is just memorization that's easy to misuse.

We'll map the architecture components, understand the core concepts (tenant, application, provider, flow, stage, policy, user & group), then follow the journey of a single request from the browser to returning with a token. Just as a pilot must understand how wings work before flying, an engineer who understands Authentik's architecture will be far faster at debugging problems in later episodes.

#Architecture Components

Authentik never runs alone. It's a coordination point among several components. Let's break them down one by one.

#Authentik Server

The heart is the server process — the web application that serves three things: the API (the front line for the web UI and integrations), the web UI (the admin interface and the user login portal), and flow execution. By default it listens on port 9000. Its image is ghcr.io/goauthentik/server. Every request from a browser or application ultimately reaches the server.

#Authentik Worker

The worker is the companion process that runs asynchronous tasks: source synchronization (LDAP, social login), email delivery, scheduled tasks, and other background jobs. It uses the same image as the server (ghcr.io/goauthentik/server) only with the command: worker command. If you see odd behavior like emails not being sent or synchronization stuck, check the worker logs first with docker compose logs -f worker.

#PostgreSQL

All of Authentik's persistent data — configuration, users, groups, applications, providers, flows, stages, policies, and events — is stored in PostgreSQL. This is the single source of truth. Losing the database means losing everything, so the backup episode makes PostgreSQL the top priority.

#Redis

Redis plays a dual role: cache (sessions, policy results, and frequently read data) and message queue (passing tasks from the server to the worker). Since it holds transient data, Redis can be rebuilt without losing data — but without Redis, Authentik won't function normally.

#Outposts

An outpost is a component that runs outside the core server and communicates with it to serve a specific need. Two main types: the proxy outpost (sits in front of applications for forward auth, image ghcr.io/goauthentik/proxy) and the LDAP outpost (presents Authentik users as an LDAP directory for legacy applications). Outposts can run embedded in the server (the lab default) or separately on another host or Kubernetes (for production).

#Web UI (Admin Interface)

The Authentik UI has two faces: the admin interface (where you manage tenants, users, flows, applications — accessed by admins) and the user interface (where users manage their profile, MFA devices, and available applications). Episode 3 will take you there.

#Core Concepts

You'll encounter these terms constantly. Understand them now so you don't get lost later:

• Tenant — an isolated scope (namespace) for branding, default flows, and configuration. Like an "apartment" in a building: walls separate, but plumbing may be shared.
• Application — an application enabled for SSO that appears in the user portal. An application is bound to a single provider.
• Provider — the protocol implementation that connects Authentik to an application: OAuth2/OIDC, SAML, LDAP, Proxy, or SCIM. Application + Provider = one SSO entry.
• Source — a connection to an external identity system: OAuth (Google, GitHub), SAML, or LDAP/Active Directory. Sources enable login with external identities.
• Flow — an authentication journey run for a single purpose: login, registration, password reset, logout, and more.
• Stage — the smallest building block in a flow: ask for username, validate password, ask for consent, and so on.
• Policy — conditional logic that returns an allow/deny result, used to control application access or steps within a flow.
• User & Group — identity entities. A user is a person (or service account), a group is a collection of users for centrally managing access.
• Outpost — a remote (proxy/LDAP) component that sits outside the core server.

#The Flow System

Flows are Authentik's main differentiator compared to other IdPs. Each flow has a designation that determines its purpose and how it's invoked:

• Authentication flow — the login flow (username, password, MFA).
• Authorization flow — a flow that runs authorization policies before access is granted.
• Enrollment flow — the flow for registering new users (sign-up).
• Unenrollment flow — the flow for deactivating an account.
• Recovery flow — the flow for account recovery (password reset).

Each flow is assembled from stages: identification, password, authenticator validation, user write, consent, email, prompt, deny, and more. Episode 4 dissects them all.

#Provider Types

• OAuth2/OIDC Provider — for modern applications; issues JWT access tokens and ID tokens.
• SAML Provider — for enterprise applications; issues XML assertions.
• Proxy Provider — for forward auth via a reverse proxy; injects identity headers.
• LDAP Provider — via an LDAP outpost; presents Authentik users as an LDAP directory.
• SCIM Provider — automated user provisioning to target applications.

#End-to-End Authentication Flow

This is the "everything comes together" moment. Follow the journey of a single request:

1. The user opens an application (for example https://grafana.example.com) integrated with Authentik via OIDC.
2. The application has no session → it redirects the user to the Authentik authorization endpoint.
3. Authentik sees the user isn't logged in → it executes the authentication flow.
4. The flow runs stage by stage: identification (username), password, then MFA if requested.
5. Once authenticated, policies are evaluated to decide whether the user may continue.
6. If needed, the authorization flow runs and the consent stage asks the user to grant the application permission.
7. Authentik issues an authorization code, and the browser is redirected back to the application.
8. The application exchanges the code for a token at the token endpoint, then reads the identity from the ID token or the UserInfo endpoint.
9. The application opens the page — for a user it now knows.

Browser            Aplikasi (SP)         Authentik
   |  1. buka app       |                      |
   |-------------------->|                      |
   |  2. redirect ke auth|                      |
   |<--------------------|                      |
   |  3. execute flow    |--------------------->|
   |  4. identification + password + MFA        |
   |<------------------->|                      |
   |  5. policies evaluasi -> 6. consent        |
   |  7. authorization code ->|                 |
   |<--------------------|  8. tukar code ->    |
   |                     |  <- id token + AT    |
   |                     |  9. halaman aplikasi |

#Glossary of Terms

#Closing

In this episode 2, you mapped Authentik's architecture: server (API + web UI + flow execution), worker (async tasks), PostgreSQL (the source of truth for data), Redis (cache and message queue), and outposts (proxy and LDAP) which can run embedded or separate. You also recognized the core concepts — tenant, application, provider, source, flow, stage, policy, user & group — and followed the end-to-end OIDC login journey from the application, to the authorization endpoint, through flows and policies, and back with a token.

Key takeaways:

• Server + worker + PostgreSQL + Redis form the backbone; outposts are the remote extension.
• Flows assemble stages; policies control the decisions within them.
• Application + Provider is one SSO entry; tenant is a namespace; source is the entry point for external identity.
• Applications never see the password — only tokens.

In episode 3, we start taking action: installing Authentik with Docker Compose — assembling the server, worker, PostgreSQL, Redis, and proxy stack, managing secrets through the .env file, bootstrapping the admin, and verifying your first Authentik UI. See you in episode 3!