authentik is an open source identity provider (IdP) that centralizes authentication, authorization and user provisioning. This lesson lays the conceptual groundwork: the main objects, the modular flows/stages/policies logic, the integration modes and the limits. There is no installation here: the lesson Install authentik with Docker Compose (in French) puts it into practice.
This module is optional: the course relies on Keycloak as the reference identity provider. authentik is presented here to discover another approach (flows, outposts, built-in proxy), not as a complete replacement for Keycloak, and no other lesson depends on it.
What you will learn
- Name authentik's main objects and the role of each one.
- Follow the flows, stages and policies logic of an authentication journey.
- Tell a provider from a source.
- Decide when an outpost is needed.
- Identify the use cases where authentik is a good fit.
The problem to solve
Local accounts multiply
In a typical DevOps environment, each tool manages its own accounts: Grafana has its users, GitLab has its own, Portainer too. When a colleague joins the team, you have to create 5 or 10 accounts. When they leave, you have to revoke them all, and one is always forgotten.
It is like handing out a different set of keys for each room of a building, with no central register. With 3 users, it is manageable. With 30, it is an operational nightmare and a security risk.
The limits of scattered authentication
Even with an LDAP directory or Active Directory, the problem is only partly solved:
- No SSO: the user types their password into every application
- No centralized MFA: some applications support it, others do not
- No automatic provisioning: accounts are created by hand
- No unified access policy: each application defines its own rules
The result: orphaned accounts, reused passwords, overly broad access and no visibility into who accesses what.
Why IAM becomes a core building block
An identity provider (IdP) solves these problems by becoming the single point of authentication. The user logs in once, and the IdP issues tokens to the applications that need them. The administrator manages users, groups and access policies from a single interface.
authentik is designed to fill exactly this role, covering a wide scope for an open source solution: SSO, federation, access proxy, SCIM provisioning (the automatic synchronization of accounts, see SCIM) and an LDAP directory, all in one product.
What authentik is
An open source, modular identity provider
authentik is an Identity Provider (IdP) that centralizes:
- Authentication: verifying who the user is (SSO, MFA, social login)
- Authorization: deciding what they can do (policies, groups, roles)
- Provisioning: creating and synchronizing accounts in the target applications
- Federation: consuming identities coming from other systems (LDAP, Active Directory, another IdP)
The project is developed in Python (Django) on the server side and TypeScript (lit-html) on the interface side. It is distributed under the MIT license and hosted on GitHub.
Which use cases does it cover?
Each use case goes through a specific authentik object: read the right-hand column as a lookup table, which the following sections detail object by object. Remember already the distinction that comes back everywhere: a provider serves an application, a source feeds authentik.
| Use case | How authentik handles it |
|---|---|
| SSO for web applications | OIDC or SAML provider |
| Centralized access portal | "My Applications" interface |
| Access proxy for incompatible apps | Proxy provider + outpost |
| LDAP directory | LDAP provider + outpost |
| Automatic provisioning | SCIM provider |
| Federation with Active Directory | LDAP source |
| Social login (Google, GitHub...) | OAuth source |
| MFA (TOTP, WebAuthn, backup codes) | Authentication stages |
What authentik does not replace
authentik is not:
- A secrets manager (for that, use HashiCorp Vault or an equivalent tool)
- An SSH bastion (for that, look at Teleport (in French) or a similar tool)
- A high-performance reverse proxy: authentik's proxy provider is built for access control, not for load balancing
- A fine-grained authorization engine such as OPA or Cedar: authentik handles authorization at the entrance (who is allowed in), not the permissions inside the application
authentik's main objects
authentik organizes its configuration around a few key objects. Understanding their role keeps you from getting lost in the administration interface.
Applications
An application in authentik represents a service you want to protect. It is the object users see in the "My Applications" portal. Each application is linked to a provider that defines how authentication works for that service.
Concretely: if you have Grafana, GitLab and an internal wiki, you will create three applications in authentik.
Providers
A provider defines the protocol and the technical parameters for connecting an application to authentik. It is the technical part of the integration.
| Provider type | Protocol | Typical use case |
|---|---|---|
| OAuth2/OIDC | OpenID Connect | Modern web applications |
| SAML | SAML 2.0 | Enterprise and legacy applications |
| Proxy | Forward Auth / Reverse Proxy | Applications without OIDC/SAML support |
| LDAP | LDAP v3 | Applications that only speak LDAP |
| SCIM | SCIM 2.0 | Automatic account provisioning |
| RADIUS | RADIUS | VPN, Wi-Fi, network equipment |
| RAC | Remote Access Control | RDP, SSH or VNC access from the browser |
The tip for getting started: use "Create with Provider" in the interface to create the application and the provider in a single step.
Sources
A source is the mirror image of a provider: instead of providing identities to an application, authentik consumes identities from an external system.
| Source type | External system | What authentik retrieves |
|---|---|---|
| LDAP | Active Directory, OpenLDAP | Users and groups |
| OAuth | Google, GitHub, Azure AD | Identity through social login |
| SAML | Another SAML IdP | Federated identity |
| SCIM | An HR system or another IdP | Provisioned users |
Outposts
An outpost is a component deployed separately from authentik, which runs a specific function on the network. It is authentik's arm outside the central platform.
There are four types of outposts:
- Proxy outpost: intercepts HTTP traffic and enforces authentication for applications that are not OIDC/SAML compatible. It works with Nginx, Traefik or Caddy through the Forward Auth mechanism: the reverse proxy asks the outpost whether the request is authorized before passing it on to the application.
- LDAP outpost: exposes an LDAP server that legacy applications can query (bind, search). The identities come from authentik.
- RADIUS outpost: provides a RADIUS server for VPNs and network equipment.
- RAC outpost (Remote Access Control): gives access to remote machines (RDP, SSH, VNC) from the browser, through the RAC provider.
Each outpost connects to authentik through an API and receives its configuration automatically. You can deploy outposts as Docker containers or Kubernetes pods.
The core of the engine: flows, stages and policies
This is the part of authentik that is most disorienting at first contact, and also the most powerful. Where Keycloak uses "Authentication Flows" with executions configured through the interface, authentik offers an even more modular system.
What a flow is
A flow is a journey the user goes through to complete an action. For example: logging in, enrolling, recovering a password, giving consent.
Each flow has a designation that defines its type:
| Designation | Purpose |
|---|---|
authentication | A user logs in |
authorization | Consent before accessing an application |
enrollment | A new user signs up |
invalidation | Logout |
recovery | Password recovery |
stage_configuration | Configuring an MFA factor |
unenrollment | Account deletion |
The role of stages
A stage is a step in a flow. Each stage represents a concrete action that the system asks of the user or runs in the background.
Examples of stages:
| Stage | What it does |
|---|---|
| Identification | Asks for the username or email |
| Password | Checks the password |
| Authenticator Validate | Asks for the MFA code (TOTP, WebAuthn...) |
| Authenticator TOTP Setup | Enrolls a new TOTP device |
| Sends a confirmation email | |
| Consent | Asks for the user's consent |
| User Write | Creates or updates the user in the database |
| User Login | Creates the user session |
| Deny | Denies access |
A typical login flow chains: Identification → Password → Authenticator Validate → User Login. If the user has no MFA configured yet, a setup stage can be inserted automatically.
The role of policies
A policy is a condition that evaluates to true or false. Policies are attached to stages (or directly to flows) to decide whether a stage must run or be skipped. This attachment is called a binding.
| Policy type | What it evaluates |
|---|---|
| Expression | Custom Python code |
| Password | Password complexity |
| Reputation | Reputation score (IP, identifier) |
| Event Matcher | Match against an event |
For example, an expression policy can check whether the user belongs to an "admins" group and, if so, require a second authentication factor. Otherwise, the MFA stage is skipped.
How these elements work together
The mechanism is simple once you can picture it:
- The user triggers a flow (they click "Log in")
- authentik walks through the flow's stages in the defined order
- Before each stage, the attached policies are evaluated: by default when the stage is presented to the user (the
re_evaluate_policiesoption of the stage binding), and in addition as soon as the flow is planned if theevaluate_on_planoption is ticked - If the policy bindings pass, the stage runs. The policy engine mode is a field of the object that receives the bindings (here the stage binding in the flow), not of each policy: in
Anymode (the default), a single binding passing is enough; inAllmode, all of them must pass - Otherwise, the stage is skipped (or the flow is interrupted)
- When all stages have been passed → the flow is complete
This mechanism is what makes authentik so flexible: you can build conditional authentication journeys without writing any code in the application.
How authentik builds an authentication journey
To make the mechanism concrete, let us follow a scenario step by step. A user clicks "Grafana" in the authentik portal.
Step 1, Redirect. Grafana is configured as an application with an OIDC provider. Grafana redirects the user to authentik with an OIDC authorization request.
Step 2, Authentication flow. authentik triggers the
default-authentication-flow flow. The first stage asks for the username or
email (Identification).
Step 3, Password. The Password stage checks the credentials. If the user has a local password, it is verified. If the user comes from an LDAP source, authentik performs an LDAP bind in the background.
Step 4, Conditional MFA. A policy checks whether the user belongs to the "mfa-required" group. If so, the Authenticator Validate stage asks for a TOTP code or a WebAuthn key. Otherwise, this stage is skipped.
Step 5, Session. The User Login stage creates the session. The user is authenticated.
Step 6, Consent. authentik checks the scopes requested by Grafana. A consent stage can ask the user to agree to share their email and groups.
Step 7, Return. authentik redirects the user to Grafana with an authorization code. Grafana exchanges it for a token and logs the user in.
All of this is configurable: you can change the order of the stages, add conditions, insert a captcha, require a verification email, or redirect to another flow.
What users see
The "My Applications" portal
End users do not see authentik's administration interface. They reach a portal that lists the applications they are entitled to. This portal is customizable: name, logo, theme and links.
Each application in the portal is clickable and redirects to the protected service; authentication is transparent thanks to SSO.
Brands
authentik supports brands: you can customize the look of the portal and of the login pages per domain. It is useful if you host several organizations or projects on the same instance.
Quick comparison with Keycloak
The two tools overlap, but their philosophy differs:
| Criterion | authentik | Keycloak |
|---|---|---|
| Language | Python (Django) | Java (Quarkus) |
| License | MIT | Apache 2.0 |
| Built-in access proxy | Yes (proxy provider + outpost) | No (needs an external component) |
| Built-in LDAP directory | Yes (LDAP outpost) | No (consumes LDAP, does not expose it) |
| SCIM | Yes (SCIM provider, pushes accounts to applications) | Native SCIM server since 26.8; pushing to applications requires an extension |
| Customizable flows | Flows / stages / policies | Authentication Flows / Executions |
| Maturity | Newer project | Old and very widespread project |
| Ecosystem | Growing community, Enterprise edition | Broad ecosystem, Red Hat commercial support |
The table gives no memory consumption figure: it depends on load and configuration. Measure on your own deployment before any sizing.
authentik is often preferred for mid-sized deployments, homelabs and projects that need the built-in proxy provider. Keycloak remains the reference choice for large organizations with complex federation needs and a need for commercial support.
When to use authentik
Favorable cases
- SSO for a set of web applications: this is the main use case. OIDC for modern apps, SAML for enterprise apps.
- Centralized access portal: the "My Applications" portal offers a single entry point. Users see only the applications they are entitled to.
- Access proxy for incompatible applications: the proxy provider avoids modifying existing applications. It is a big advantage over Keycloak, which does not offer this feature natively.
- Automated provisioning: with SCIM, authentik creates and synchronizes accounts in the target applications. Fewer orphaned accounts, less manual work.
- Homelab or mid-sized infrastructure: the Docker Compose installation is simple, and resource consumption is reasonable.
Less suitable cases
- Large organization where commercial support is mandatory: Keycloak benefits from Red Hat support (Red Hat build of Keycloak). authentik offers an Enterprise edition, but the support ecosystem is smaller.
- Very specific compliance needs (FIPS, Common Criteria certification): check what each product documents and certifies before committing.
- Infrastructure without containers: authentik is distributed exclusively as Docker images. There is no official bare metal installation.
Key takeaways
- authentik is a complete IdP: SSO, federation, proxy, LDAP, SCIM and MFA in a single product.
- Each protected service is an application, linked to a provider that defines the protocol.
- A provider provides identities to an application, a source consumes identities from an external system.
- Flows define the journeys, stages the steps, policies the conditions. The
policy engine mode, set on the object that receives the bindings, decides the
outcome: in
Anymode (the default), a single binding passing is enough, inAllmode they must all pass. - Outposts (Proxy, LDAP, RADIUS, RAC) are deployed separately and connected to authentik through an API.
- The default flows are enough to get started: customize only when a concrete need requires it.