Authelia или Authentik: что выгоднее и когда

MAATRIX

Рано или поздно домашний или рабочий сервер обрастает десятком сервисов за reverse-proxy, и вопрос «как один раз залогиниться и получить доступ ко всему» становится не роскошью, а необходимостью. Тут и всплывают два имени — Authelia и Authentik. Оба бесплатны, оба открыты, оба умеют forward-auth для Traefik и Caddy, но это два разных инструмента с разной философией, и выбор не «что лучше», а «что не станет обузой через полгода».

Что это вообще такое

Authelia — это легковесный компаньон для reverse-proxy. Один статический бинарник (или контейнер) на Go, YAML-конфиг, встроенная поддержка 2FA (TOTP, WebAuthn), портал логина и forward-auth middleware. Она не пытается быть полноценным identity provider — это скорее «страж на входе», который решает: пускать запрос дальше к nginx/Traefik/Caddy или отправлять на страницу логина.

Authentik — это полноценный IdP (identity provider) в духе Keycloak, только легче и с более современным UI. Django + Celery + PostgreSQL + Redis под капотом, полноценный OAuth2/OIDC-сервер, SAML IdP и SP, SCIM, LDAP-провайдер, гибкие policy-flows, где логику логина можно собрать визуально из блоков (стадии, условия, действия). Authentik может быть единственным identity-сервером для десятков приложений сразу — не только для reverse-proxy защиты, но и как настоящий SSO для Grafana, GitLab, Nextcloud и любого приложения с OIDC/SAML.

Разница примерно как между дверным замком с кодовой панелью и полноценным бюро пропусков с фотографированием и учётом визитов — оба закрывают дверь, но зона ответственности разная.

Архитектура и стек

Authelia — один контейнер (можно и без БД, конфиг в YAML, пользователи в файле или LDAP). Минимальный стек:

services:
  authelia:
    image: authelia/authelia:4.38
    volumes:
      - ./config:/config
    environment:
      - TZ=Europe/Moscow
    restart: unless-stopped
    networks:
      - proxy

Хранилище сессий может быть SQLite (по умолчанию, для одного инстанса) или PostgreSQL + Redis, если нужна отказоустойчивость на несколько реплик.

Authentik требует полноценный стек с самого начала:

services:
  postgresql:
    image: postgres:16-alpine
    environment:
      POSTGRES_PASSWORD: ${PG_PASS}
      POSTGRES_USER: authentik
      POSTGRES_DB: authentik
    volumes:
      - db-data:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine
    command: --save 60 1

  server:
    image: ghcr.io/goauthentik/server:2024.10
    command: server
    environment:
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_REDIS__HOST: redis

  worker:
    image: ghcr.io/goauthentik/server:2024.10
    command: worker

Четыре контейнера вместо одного — это не прихоть, а следствие архитектуры: сервер обрабатывает HTTP, worker крутит фоновые задачи (email, синхронизация LDAP, flows), Redis — брокер и кэш, Postgres — источник правды. Отдельные готовые compose-файлы под оба варианта разобраны в статьях Authelia в Docker Compose и Authentik в Docker Compose.

Установка и порог входа

С Authelia от docker compose up до рабочего портала логина — минут пятнадцать, если конфиг уже под рукой. Основная конфигурация — один YAML-файл configuration.yml, где описаны access control rules, провайдер аутентификации (file, LDAP) и сессии. Пошаговая установка с нуля разобрана в статье Authelia на Ubuntu 24.04: пошаговая установка.

access_control:
  default_policy: deny
  rules:
    - domain: "grafana.example.com"
      policy: two_factor
    - domain: "public.example.com"
      policy: bypass

С Authentik порог входа выше не из вредности, а по устройству: нужно поднять Postgres и Redis, дождаться миграций (первый запуск может занять пару минут), пройти visual-мастер настройки admin-аккаунта через веб-интерфейс, а затем собирать flow логина через UI — стадии identification, password, MFA, consent соединяются в граф. Это мощно, но требует понимания концепции flows, которая на старте выглядит избыточной для простой задачи «защитить дашборд Grafana паролем и TOTP». Подробный разбор установки — в статье Authentik на Ubuntu 24.04: пошаговая установка.

Честно: если у вас три-пять внутренних сервисов и задача «попросить пароль и код на входе» — Authentik для этого явно избыточен на старте, даже если потом пригодится.

Протоколы и что каждый умеет как identity provider

Здесь граница проходит резко.

Authelia:

• forward-auth / auth-request для nginx, Traefik, Caddy, HAProxy — это её основной режим работы;
• OpenID Connect провайдер появился начиная с 4.38, но это дополнение, а не изначальная цель — набор возможностей уже, чем у специализированных IdP;
• SAML не поддерживается вовсе;
• LDAP и file backend как источники пользователей — сама Authelia провайдером identity для сторонних сервисов исторически не была, это добавилось позже.

Authentik:

• полноценный OAuth2/OIDC provider с поддержкой authorization code, client credentials, device flow;
• SAML IdP и SP (может выступать и в роли сервис-провайдера);
• SCIM для синхронизации пользователей во внешние системы;
• LDAP-провайдер — то есть Authentik сам может отдавать LDAP наружу для приложений, которые понимают только LDAP;
• forward-auth для reverse-proxy — тоже есть, как один из режимов, но это не основная специализация, а один из многих провайдеров.

Если задача — SSO для GitLab, Nextcloud, Grafana, Jenkins и десятка других приложений с их родным OIDC/SAML клиентом, Authentik закрывает это нативно и без костылей. Если задача — единая точка входа перед reverse-proxy для набора внутренних веб-морд без встроенной авторизации, Authelia справляется тем же результатом при кратно меньшем весе. Похожий по духу выбор описан в статье Traefik или Nginx Proxy Manager: что выбрать для сервера — принцип «не берите тяжёлое решение под лёгкую задачу» работает и здесь.

Ресурсы и что не утянет бюджетный VPS

Здесь тоже разница не в проценты, а в разы, хотя точные цифры зависят от числа пользователей, длины сессий и параметров логирования — приводим ориентиры, не гарантированные значения.

На VPS с 1–2 ГБ RAM, где крутится ещё и сам защищаемый сервис плюс reverse-proxy, Authentik со своим Postgres+Redis+Celery легко съедает половину и больше доступной памяти ещё до нагрузки. Authelia в том же сценарии — заметно менее прожорливый сосед. Подробные цифры и как их проверить на своём сервере — в статьях сколько RAM нужно для Authelia и сколько RAM нужно для Authentik.

Практический вывод: на дешёвом VPS 1–2 ГБ ставьте Authelia, если задача укладывается в её возможности. Authentik туда тоже поместится технически, но с очень маленьким запасом на всё остальное — комфортнее он чувствует себя от 4 ГБ и выше, особенно если добавляются LDAP-синхронизация и SAML-интеграции, которые грузят worker.

Когда что выбрать: сценарии

Берите Authelia, если:

• у вас набор внутренних веб-сервисов за одним reverse-proxy (Traefik/nginx/Caddy) и нужен единый логин + 2FA перед ними;
• ресурсы сервера ограничены, а лишний Postgres/Redis заводить не хочется;
• источник пользователей — простой YAML-файл или уже существующий LDAP/AD, без сложной логики;
• нужен минимум движущихся частей для домашней лаборатории или небольшой команды.

Берите Authentik, если:

• нужен полноценный SSO для приложений, которые сами говорят по OIDC/SAML (Grafana, GitLab, Nextcloud, Zabbix и т.п.), а не только forward-auth перед прокси;
• планируется рост: несколько десятков пользователей, группы, ролевой доступ, интеграция с внешними каталогами;
• нужен LDAP-провайдер наружу для legacy-приложений, которые сами по себе LDAP не отдают;
• готовы держать полноценную БД под identity-слой и не считаете 1 ГБ RAM критичным ограничением.

Есть и третий вариант — Keycloak, если организация уже крупная и нужна максимальная гибкость enterprise-уровня; сравнение возможностей и требований к ресурсам — в статье про Keycloak на Ubuntu 24.04. Для большинства self-hosted сценариев на VPS выбор всё же между Authelia и Authentik, а Keycloak — следующая ступень, когда обе предыдущие становятся тесны.

Комбинировать их тоже можно: например, поставить Authentik как центральный IdP, а перед частью легаси-сервисов, которым OIDC не завезли, добавить Authelia в forward-auth режиме, настроив её на тот же LDAP-провайдер от Authentik. Это усложняет схему, но иногда закрывает разрыв между «хочу SSO для всего» и «у половины сервисов нет клиента OIDC».

Частые вопросы