authentik: a self-hosted identity provider for SAML, OIDC and LDAP

What authentik replaces, and for whom

The README describes authentik as "an open-source Identity Provider (IdP) for modern SSO" that supports SAML, OAuth2/OIDC, LDAP, RADIUS, and more, and says it is "designed for self-hosting from small labs to large production clusters". That sentence is the whole pitch. Instead of every internal application holding its own user table and password reset flow, the applications trust authentik, and authentik holds the accounts, the groups, the MFA factors and the session.

The audience is narrower than "anyone who wants SSO". You need to be willing to run a stateful service. The dependency list in pyproject.toml includes django-tenants, psycopg with the C and pool extras, and django-channels-postgres, which tells you the deployment expects PostgreSQL and a channel layer rather than SQLite on a laptop. If you are a single developer with three services, the operational cost of that stack is larger than the problem you are solving. If you are a small company with a wiki, a Git server, a Nextcloud instance and a NAS, and you are paying per-seat prices to a hosted provider, the arithmetic changes quickly.

The README also points at an enterprise offering, framed as a way for organizations to "securely replace existing IdPs such as Okta, Auth0, Entra ID, and Ping Identity". Read that as a positioning statement about the commercial tier, not as a claim that the open source build is a demo. The repository ships the full application under authentik/, with the enterprise pieces in a separate directory.

How the identity provider and its outposts fit together

The repository layout shows one large Python application and a set of smaller services written in other languages. The Python side is the core: Django models, the admin interface, the policy engine, the flows users click through, and the API that drf-spectacular documents. Around it sit Go and Rust components. The go.mod file pulls in beryju.io/ldap, beryju.io/radius-eap, layeh.com/radius and go-ldap, which is the clearest signal that LDAP and RADIUS are served by a separate process rather than by Django itself. The Cargo.toml workspace lists packages/ak-axum, packages/ak-common and packages/client-rust, so part of the request path is handled by Rust as well.

The pattern behind this is the outpost. The core decides who a user is and what they may access; an outpost sits closer to the protected resource and enforces that decision for a protocol the core does not want to terminate directly. The README's CI badges name a separate outpost workflow, and the Go dependencies for LDAP and RADIUS line up with that split. Practically, this matters when you debug: a broken LDAP bind is not a Django problem, and the logs you need will be in the outpost container, not the server container.

State lives in PostgreSQL. Sessions, flows, and the tenant-scoped objects all go through the database layer, and django-pglock and django-pgtrigger in the dependency list suggest the project leans on PostgreSQL features rather than treating it as a generic key-value store. That is a design commitment: you cannot swap in MySQL, and backups are database backups.

Installing authentik for a first SSO login

The README lists four installation routes: Docker Compose, which it calls "recommended for small/test setups"; Kubernetes via a Helm chart, "recommended for larger setups"; AWS CloudFormation; and a DigitalOcean Marketplace app. Each entry links to its own page under docs.goauthentik.io. The README does not reproduce any compose file or command, so the installation steps live on those documentation pages rather than in the repository.

What the repository does tell you is what the running stack needs. The Python dependencies include psycopg with the C and pool extras and django-channels-postgres, so a PostgreSQL database and a channel layer are part of the deployment. The version files give you the tag to pin: pyproject.toml and Cargo.toml both carry 2026.11.0-rc1, while the most recent stable release listed in the repository is version/2026.8.0. Pin the stable tag for anything you intend to keep running.

Once the stack is up, the first real task is not adding users. It is creating a provider and an application. A provider describes the protocol (OIDC, SAML, LDAP, RADIUS, SCIM) and the application binds it to a launch URL and a policy. That pairing is the unit you repeat for every service you connect, and it is the step that decides whether a login attempt reaches authentik at all.

For development work, the repository root carries manage.py alongside pyproject.toml and uv.lock, and the README points at the Developer Documentation for setting up local build environments and testing contributions. The frontend workspace is pnpm-based: package.json declares engines of node >=24 and pnpm >=12.4.0, and the scripts it exposes are check-types, lint, lint:catalogs, lint:runtime and lint:spellcheck.

Where authentik is the wrong tool

The strongest argument against authentik in a given environment is not a missing protocol. It is the number of moving parts you now own. A PostgreSQL instance, a channel layer, a server process, a worker process, at least one outpost, and a reverse proxy that terminates TLS in front of all of it. Every one of those is a thing that can be down at 8am. A hosted provider absorbs that risk and charges you for it; authentik moves the risk onto your team and removes the invoice.

There is a second, quieter limitation. The dependency list is pinned tightly. Django is pinned to 5.2.17, Python is pinned to 3.14.*, and the Rust workspace pins nearly every crate with an exact version. That is good for reproducibility and bad for anyone who wants to run authentik inside an application they also control, or to patch a transitive dependency on their own schedule. You are expected to upgrade by moving to the next authentik release, not by resolving your own dependency graph.

The repository also mixes licences. The README's licence section links three separate files: LICENSE at the root, website/LICENSE, and authentik/enterprise/LICENSE. The repository metadata reports the licence as NOASSERTION, which is GitHub's way of saying it could not classify what it found. If your organisation has rules about which licence texts are acceptable, read all three files before you deploy, and treat the enterprise directory as governed by its own terms.

How authentik differs from Keycloak and Authelia

Keycloak is the obvious comparison, and it is a fair one: both are self-hosted identity providers that speak SAML and OIDC. The difference is in what they are built out of and what that implies for operations. Keycloak is a Java application; authentik is a Django application with Go and Rust outposts alongside it, and its dependency list is dominated by the Python and PostgreSQL ecosystem. If your team already runs Postgres and containers and reads Python, authentik's failure modes will look familiar. If your team runs the JVM and has run Keycloak for years, switching buys you a different set of unfamiliar failure modes and not much else.

Authelia sits at a different layer. It is a forward-auth companion to a reverse proxy: the proxy asks Authelia whether a request may proceed, and Authelia answers. authentik can play that role too, but it also acts as the source of truth for accounts and issues tokens directly to applications through OIDC and SAML. Choosing between them is mostly a question of whether you want an identity provider or an authentication gate. If all you need is a login page in front of a handful of dashboards plus a group membership check, Authelia is a smaller thing to run. If applications need to consume tokens, receive SCIM provisioning, or bind over LDAP, the identity provider is the right shape.

A third option is to keep a hosted provider and stop reading. That is a legitimate answer for a team of five with no infrastructure engineer, and authentik's own README frames the enterprise tier as the path for organisations replacing Okta or Entra ID at scale.

Upgrade cadence, licence and what it costs to stay current

The release history shows a regular rhythm: 2026.8.0-rc6 on 2026-08-03, 2026.8.0-rc7 on 2026-08-10, and 2026.8.0 on 2026-08-18. The version scheme is calendar-based, and the repository's own package.json and pyproject.toml already carry 2026.11.0-rc1, so the next cycle was in progress when the stable release landed. The last push to the default branch was on 2026-08-18.

That cadence is the real maintenance cost. A calendar version scheme with a new release every few months means you either track releases or you fall behind, and identity software is not a component you want to leave unpatched for a year. The upgrade path itself is a container image swap plus migrations, which is routine, but it is routine work that recurs. Budget for reading release notes each cycle rather than treating the install as finished.

On licensing, the repository does not present a single clean answer. The root LICENSE, website/LICENSE and authentik/enterprise/LICENSE are three separate files, and the repository reports the overall licence as NOASSERTION. That is not a legal opinion and this is not legal advice; it is a signal that you should read the files yourself and confirm which one covers the code you intend to run in production. Organisations with licence review processes should route all three files through that process before deployment, not after.

Editorial conclusion

Adopt authentik if you already run containers or Kubernetes and need SAML, OIDC, LDAP or RADIUS behind one login page under your own control. Do not adopt it if nobody on the team can operate Postgres and a reverse proxy, or if you need a hosted service with a support contract and no infrastructure work. Before committing, verify the exact authentik version tag you will pin, confirm your reverse proxy passes the required headers, and read the enterprise licence file at authentik/enterprise/LICENSE rather than assuming the whole repository is covered by one licence.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes