Инструменты для самостоятельно развёрнутого SSO и управления доступом

Недавно один автор из XDA прошёлся по четырём шагам, которые он сделал, чтобы защитить сервер Plex перед тем, как открыть его в интернет: обеспечить TLS, перестать рекламировать порт 32400 прямо через маршрутизатор, поставить обратный прокси и включить двухфакторную аутентификацию для учётной записи. Всё разумно. Всё неполно. Обратный прокси завершает TLS и маршрутизирует имена хостов, а затем передаёт запрос приложению, которому остаётся решать самостоятельно, должен ли человек на другом конце там находиться. Каждый сервис получает свою страницу входа, свои правила для пароля и своё понимание того, что означает «выход из системы».

Этот пробел заполняют лучшие приложения для самостоятельно развёрнутого SSO. Один поставщик идентификации находится позади обратного прокси, каждый сервис обращается к нему, MFA применяется один раз для всех, и удаление доступа у кого-то — это один переключатель вместо путешествия по двенадцати панелям администратора. Мы посмотрели на 8 вариантов, которые активно разрабатываются и запущены в реальных домашних лабораториях сегодня, от полных поставщиков идентификации со своей базой данных до одного контейнера, который ответит на один вопрос «да или нет» на каждый запрос.

На что смотреть при выборе приложения для самостоятельно развёрнутого SSO

Быстрое сравнение

Приложение Лучше всего для Собственное хранилище пользователей Протоколы Forward auth Лицензия
Authentik Полный поставщик идентификации с веб-интерфейсом Да OIDC, SAML, LDAP, RADIUS Да, proxy outpost MIT core, платный enterprise tier
Authelia Лёгкий портал рядом с вашим обратным прокси Да, файл или LDAP OIDC provider, forward auth Да, native Apache 2.0
Tinyauth Получить любой login перед несколькими приложениями быстро Да, плюс OAuth и LDAP OIDC, forward auth Да, native AGPL 3.0
LLDAP Одна общая папка, которую остальные могут читать Да, только LDAP LDAP Нет GPL 3.0
oauth2-proxy Прикрепление существующего IdP к одному приложению Нет OIDC и OAuth2 client Да, через nginx auth_request MIT
Zitadel Журналы аудита и многопользовательские установки Да OIDC, SAML, SCIM, LDAP Via OIDC AGPL 3.0
Keycloak Самое широкое покрытие протоколов и федерации Да OIDC, SAML Via oauth2-proxy Apache 2.0
Pomerium Политика за запрос в самом прокси Нет OIDC client Это сам прокси Apache 2.0

Почему уровень идентификации — это тот, который люди пропускают

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

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

Приложения

1. Authentik: лучший для самостоятельно развёрнутого SSO

Authentik — это тот, на который заканчивают большинство домашних лабораторий, и по хорошей причине: он охватывает обе части проблемы. Приложения, которые говорят OIDC или SAML, получают правильного поставщика идентификации с конечной точкой обнаружения, группировать утверждения и экраны согласия. Приложения, которые ничего не говорят, получают proxy outpost, который ваш обратный прокси вызывает как forward auth и который передаёт аутентифицированное имя пользователя и email вниз как заголовки. Всё настраивается через веб-интерфейс, включая конструктор потоков, который позволяет вам решить ровно когда MFA требуется и когда сеанс может быть переиспользован. Регистрация, восстановление и сброс пароля самообслуживаемы, что имеет значение в тот момент, когда кто-то кроме вас нуждается в аккаунте.

Где это не удаётся: это самый тяжёлый из лёгких вариантов. Развёртывание по умолчанию — это контейнер сервера, контейнер рабочего, Postgres и Redis, и проект просит примерно 2 ядра CPU и 2 GB RAM до того, как вы добавите что-нибудь. Система потоков мощная и соответственно легко неправильно настраивается, и прерванный поток аутентификации блокирует вас из интерфейса администратора так же эффективно, как она блокирует всех остальных.

Стоимость: ядро имеет лицензию MIT и бесплатно без ограничений на пользователей. Платный enterprise tier добавляет поддержку и функции, направленные на компании, а не на домохозяйства.

Платформы: Docker или Kubernetes в Linux, и Docker Desktop в Windows и macOS.

Загрузить: goauthentik.io · GitHub

Вывод: запустите Authentik для самостоятельно развёрнутого SSO, если вам нужна одна система, которая обрабатывает как современные приложения, так и те, которые никогда не реализуют OIDC, и у вас есть RAM, чтобы пожертвовать.

2. Authelia: лучший лёгкий вариант с конфигурацией, которую вы можете контролировать версиями

Authelia — это один бинарный файл Go, который находится рядом с вашим обратным прокси и отвечает на один вопрос за запрос. Пользователи живут в файле YAML или LDAP папке, которой Authelia не владеет, правила доступа живут в том же YAML, и вся конфигурация — это один артефакт, который вы можете коммитить в приватный репозиторий и восстанавливать за минуту. Он поддерживает TOTP, WebAuthn ключи безопасности, Duo push и passkeys, и он имеет сертификат OpenID как OIDC провайдер, поэтому приложения, которые говорят OIDC, могут общаться с ним непосредственно, чем проходить через заголовки. Интеграции forward auth задокументированы для nginx, Traefik, Caddy, HAProxy и Envoy.

Где это не удаётся: интерфейса администратора нет. Добавление пользователя означает редактирование файла и перезагрузку, что в порядке для домохозяйства и болезненно для чего-то большего. Сброс пароля нуждается в рабочей конфигурации почты. Синтаксис регистрации клиента OIDC неумолим, и опечатка в URI перенаправления производит сообщение об ошибке, которое не говорит вам, какой из двух концов неправильный.

Стоимость: бесплатно и имеет лицензию Apache 2.0.

Платформы: Docker или статический бинарный файл в Linux, плюс Docker в Windows и macOS.

Загрузить: authelia.com · GitHub

Вывод: правильный выбор, если ваши правила доступа стабильны, вам удобно в YAML и вы бы предпочли резервную копию одного файла, чем одну базу данных.

3. Tinyauth: лучший для получения login перед вещами сегодня вечером

Tinyauth — это то, на что вы ориентируетесь, когда Authelia ощущается как слишком много церемонии. Один контейнер, одна конфигурация и страница входа перед чем-либо, что ваш обратный прокси маршрутизирует ему. Он обрабатывает локальных пользователей, LDAP и логины OAuth от провайдеров, таких как GitHub и Google, поддерживает TOTP и применяет правила доступа за приложением. Версия 5.1.0 получила сертификацию OpenID для Basic OP профиля в середине 2026, поэтому это больше не только forward-auth shim: приложения, которые говорят OIDC, могут использовать его как своего провайдера. Задокументированные интеграции охватывают Traefik, nginx и Caddy.

Где это не удаётся: это молодо, и сам проект предупреждает, что конфигурация часто меняется между выпусками, поэтому обновления нуждаются в чтении примечаний выпуска, чем в слепом вытягивании нового тега. Нет SAML, нет RADIUS и нет самообслуживающейся регистрации для людей, которые ещё не в папке. Если ваша домашняя лаборатория растёт дальше горсти сервисов с различными группами, вы её перерастёте.

Стоимость: бесплатно и имеет лицензию AGPL 3.0.

Платформы: Docker в Linux, Windows и macOS.

Загрузить: tinyauth.app · GitHub

Вывод: самый быстрый честный ответ на «там вообще нет логина перед этим», и достаточно маленький, чтобы он стоил почти ничего, чтобы работать рядом с чем-то большим позже.

4. LLDAP: лучший для одной папки пользователей, которую всё остальное может читать

LLDAP — это не портал SSO. Это маленький сервер Rust, который говорит достаточно LDAP для другого программного обеспечения для аутентификации против, с веб-интерфейсом для управления пользователями и группами и опцией для пользователей, чтобы сбросить свой собственный пароль по электронной почте. Этот узкий объём — это точка: Authelia, Authentik, Keycloak, Nextcloud, Jellyfin и длинный список самостоятельно развёрнутых приложений все могут читать из него, поэтому вы получаете одно место, где аккаунты создаются и одно место, где они отключаются. Он хранит данные в SQLite по умолчанию, с MySQL, MariaDB и PostgreSQL как альтернативами, и раскрывает GraphQL API, если вы управляете пользователями из кода.

Где это не удаётся: это намеренно не полный сервер LDAP. Браузеры родовых LDAP часто отказывают против него, его схема хеширования пароля означает, что это не может раздавать хеши для другого сервиса для проверки, и проект называет Synology как несовместимый. Это не делает никакой авторизации своей собственной, поэтому что-то другое по-прежнему должно применять правила доступа.

Стоимость: бесплатно и имеет лицензию GPL 3.0.

Платформы: Docker или бинарный файл в Linux и Docker в Windows и macOS.

Загрузить: GitHub

Вывод: сочетайте его с Authelia или Tinyauth, когда вы хотите общей папки без развёртывания реального LDAP, и пропустите его полностью, если ваш поставщик идентификации уже владеет вашими пользователями.

5. oauth2-proxy: лучший для помещения IdP, который вы уже запускаете перед одним приложением

oauth2-proxy не имеет аккаунтов своей собственной. Это клиент, который отправляет посетителей поставщику OIDC или OAuth2, который у вас уже есть, проверяет результат, а затем либо проксирует запрос через к вашему приложению, либо ответ на auth_request nginx с да или нет. Он поддерживает родовой OIDC наряду с выделенными интеграциями для Google, Microsoft Entra ID, GitHub и других, и реализации, специфичные поставщику, могут вытягивать членство в группе и передавать его вниз как заголовки. Это проект CNCF Sandbox и он тихо делает эту работу много лет.

Где это не удаётся: оно решает ровно одну проблему и ожидает, что вы решили остальные. Нет управления пользователем, нет MFA своей собственной и нет механизма политики за пределами разрешающих списков адресов электронной почты, доменов и групп. Получение утверждений о группе через приложение означает сопоставление имён утверждений вашего провайдера вручную, и режим отказа — это успешный логин без разрешений.

Стоимость: бесплатно и имеет лицензию MIT.

Платформы: Docker или бинарный файл в Linux, macOS и Windows.

Загрузить: oauth2-proxy docs · GitHub

Вывод: правильный выбор, когда вы уже запускаете Authentik, Keycloak или Zitadel и нуждаетесь в одном упрямом приложении, чтобы уважать это.

6. Zitadel: лучший, когда вы хотите журнал аудита каждого события идентификации

Zitadel — это платформа идентификации Go, построенная на sourcing события, что означает каждое изменение пользователя, роли или сеанса хранится как неизменяемое событие, а не обновлённая строка. Для домашней лаборатории это звучит как чрезмерная инженерия до первого раза, когда вам нужно ответить, когда был создан аккаунт и кем. Это охватывает OIDC, SAML 2.0, OAuth 2.0, SCIM 2.0 и LDAP, поддерживает OTP по приложению, электронной почте и SMS, плюс U2F и FIDO2 passkeys, и многопользовательский из земли, если вы хостите сервисы для более чем одного домохозяйства или побочного бизнеса.

Где это не удаётся: это требует PostgreSQL 14 или позже, и установка предполагает, что вы понимаете модель организации и проекта, прежде чем вы создаёте своё первое приложение. Дизайн первых API отличный, если вы скриптируете вашу инфраструктуру и тяжелее необходимого, если вы просто хотите страницу логина. Самостоятельное хостирование AGPL 3.0, что стоит прочитать, если вы планируете построить что-нибудь коммерческое на вершине.

Стоимость: бесплатно самостоятельно хостировать. Размещённый сервис выставляется отдельно.

Платформы: Docker или Kubernetes в Linux, плюс бинарные файлы для Linux и macOS.

Загрузить: zitadel.com · GitHub

Вывод: выберите Zitadel над Authentik, когда логирование в стиле соответствия или многопользовательность является реальным требованием, чем хорошая идея.

7. Keycloak: лучший для самого широкого покрытия протокола и федерации

Keycloak — это опция предприятия, теперь проект CNCF с более чем десятилетием производственного использования позади него. Если кусок программного обеспечения поддерживает SSO в вообще, он почти наверняка задокументирует интеграцию Keycloak. Оно объединяет существующий LDAP и Active Directory, брокеры внешним провайдерам, делает тонко-зернистую авторизацию со своим собственным механизмом политики и обрабатывает неудобные углы SAML, которые более лёгкие инструменты пропускают. Начать действительно быстро с start-dev в Docker, которое работает против встроенной базы данных для оценки.

Где это не удаётся: start-dev — это не производственная конфигурация, и перемещение в один означает внешнюю базу данных, конфигурацию имени хоста, которая спотыкается почти все в первый раз, и время выполнения Java, чьё использование памяти начинается, где Authelia заканчивается. Это не имеет режима forward-auth своего собственного, поэтому приложения, которые не говорят OIDC или SAML, нуждаются oauth2-proxy впереди них. Консоль администратора предполагает словарь (realms, clients, mappers), который никакое домашнее руководство лаборатории не обучит вас.

Стоимость: бесплатно и имеет лицензию Apache 2.0.

Платформы: Docker или распределение Java в Linux, Windows и macOS.

Загрузить: keycloak.org · GitHub

Вывод: стоит стоимости установки, если вам нужна SAML федерация или вы практикуете для того же стека на работе, и сложно оправдать для шести контейнеров позади Traefik.

8. Pomerium: лучший для политики, решённой за запрос, не за логин

Pomerium инвертирует обычное устройство. Вместо поставщика идентификации, который дарует сеанс и прокси, который ему доверяет, Pomerium — это прокси, и он оценивает политику на каждый одиночный запрос, используя идентификацию из поставщика OIDC выше по цепочке плюс контекст о самом запросе. Политики написаны как конфигурация, чем щёлкнули вместе, поэтому правила доступа живут в том же репозитории, как остаток вашей инфраструктуры. Это clientless, означающее никто не должна установить приложение VPN, чтобы достичь внутреннего сервиса, и это имеет лицензию Apache 2.0 с отдельно проданной управляемой плоскостью управления для организаций, которые хотят GUI.

Где это не удаётся: это не имеет пользователей, поэтому вам всё ещё нужен Authentik, Keycloak, Zitadel или размещённый провайдер позади него. Типичное развёртывание — это больше чем один контейнер с постоянным хранилищем. И потому что это заменяет ваш обратный прокси, чем находится рядом с ним, принятие Pomerium означает переделку маршрутизирования и сертификатов, которые уже работают, что много плохого для домашней лаборатории, которая просто хочет страницу логина.

Стоимость: бесплатно и открыт исходный код самостоятельно хостировать. Размещённая плоскость управления — платный продукт.

Платформы: Docker или Kubernetes в Linux, плюс бинарные файлы для Linux и macOS.

Загрузить: pomerium.com · GitHub

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

Трение, которое никто не упоминает в руководствах установки

Половина ваших приложений не говорит OIDC. Forward auth — это fallback: обратный прокси спрашивает поставщика идентификации и в случае успеха передаёт заголовки, как Remote-User и Remote-Email к приложению. Это только работает, если приложение может быть настроено на доверие этим заголовкам, и это только безопасно, если приложение недостижимо, кроме как через прокси. Привязать контейнер к внутренней сети Docker, чем порт хоста, потому что приложение, которое верит заголовкам идентификации, поверит им от кого-угодно, кто может достичь его непосредственно.

Когда поставщик идентификации отключён, всё отключено. Postgres заполняет диск, обновление контейнера не удаётся, сертификат истекает, и внезапно ничего в доме не логирует в. Решить path для чрезвычайных ситуаций, прежде чем вам нужно это: держать по меньшей мере один маршрут к вашей инфраструктуре, который не проходит через поставщика идентификации, как SSH по mesh VPN или консоль доступ на локальной сети, и знать, какой сервис вы временно исключили бы из forward auth, чтобы восстановить остаток. Напишите это где-то, что не позади логина, который вы просто потеряли.

Резервные копии должны охватывать хранилище идентификации, не только конфигурацию. Для Authelia состояние — это файл YAML плюс маленькая база данных регистраций TOTP и WebAuthn. Для Authentik, Zitadel или Keycloak это база данных Postgres плюс ключ тайны, и восстановление базы данных без соответствующей тайны даёт вам сервис, который начинает и затем отказывает каждый сеанс. Сделайте снимок базы данных по графику, храните тайну отдельно и протестируйте восстановление один раз, чем открывая разрыв во время сбоя.

SSO перед медиа-сервером ломает родные приложения. Это специфический капкан в сценарии Plex. Приложение телевизора или мобильный клиент не могут завершить поток входа на основе браузера, поэтому помещение forward auth по всему имени хоста прекращает подключение этих клиентов полностью. Обычный workaround исключает пути API из SSO, которые спокойно возвращают вас к собственной аутентификации медиа-сервера для ровно трафика, который переносит вашу библиотеку. Более чистый ответ — это держать родной-клиент трафик на mesh VPN и применять SSO к только веб-интерфейсу, или использовать поставщика идентификации, который медиа-сервер поддерживает непосредственно, чем обёртывающее это извне.

Никогда не делайте поставщика идентификации самой слабой ссылкой. Его интерфейс администратора должен быть доступен только из вашей внутренней сети или по VPN, MFA должна быть обязательна для каждого аккаунта, который может изменить политику, и проверка сертификата остаётся везде. Неправильно настроенный поставщик идентификации хуже, чем нет, потому что это концентрирует доступ вместо распределения его.

Как выбрать правильный

Для большинства людей, открывающих домашний сервер в интернет в первый раз, честный ответ — это Authentik, если оборудование может его носить, и Authelia, если это не может. Оба дают вам один логин, применённый MFA и одно место, чтобы отозвать доступ, что весь смысл.

FAQ

Какое лучшее самостоятельно развёрнутое решение SSO для домашней лаборатории?

Authentik охватывает самый широкий диапазон ситуаций, потому что это работает как полный поставщик идентификации для приложений, которые говорят OIDC или SAML и как forward-auth шлюз для приложений, которые говорят ни одного. Authelia — это лучше подходит на ограниченном оборудовании или когда вы хотите всю конфигурацию в файле, контролируемом версией. Оба бесплатны и оба применяют MFA по каждому сервису позади них.

Мне нужен SSO, если мой обратный прокси уже имеет TLS и пароль?

Они решают различные проблемы. TLS защищает трафик в пути и базовый auth защищает один имя хоста с общей тайной, которая не может быть отозвана за человека или поддержана MFA. SSO даёт каждому человеку его собственную идентификацию, применяет второй фактор один раз для всего и позволяет вам удалить доступ в одно место. Обратный прокси — это где SSO применяется, не заменитель для этого.

Я могу положить SSO перед Plex или Jellyfin?

Отчасти. Веб-интерфейс работает хорошо позади forward auth. Родные приложения на телефонах, телевизорах и боксах потока не могут завершить логин браузера, поэтому они ломают, если вы не исключаете пути API, которые ослабляют защиту для трафика, который имеет значение наиболее. Держать родные клиенты на mesh VPN и защищать веб-интерфейс с SSO, или использовать поставщика идентификации, который медиа-сервер интегрирует с непосредственно.

Что происходит, если мой поставщик идентификации находится офлайн?

Каждый сервис позади него прекращает приём логинов, и существующие сеансы истекают на их нормальный график. План для этого: держать локальный сетевой или VPN доступ к вашему хосту, который не зависит от поставщика идентификации, держать задокументированный способ отключить forward auth на одном сервисе, и хранить коды восстановления и резервные копии базы данных где-то достижимо без логирования в.

Является ли Keycloak чрезмерным для домашнего сервера?

Обычно да. Сила Keycloak — это SAML федерация, брокерство внешним провайдерам и тонко-зернистая авторизация в организационной масштабе, и его стоимость — это время выполнения Java, внешняя база данных и словарь, который вы должны узнать сначала. Для дюжины контейнеров позади обратного прокси, Authentik или Authelia доставляют тот же практический результат с гораздо меньше установки.

Эти инструменты хранят мои пароли и как я резервную копию их?

Authentik, Authelia, Zitadel, Keycloak, LLDAP и Tinyauth все держат учётные данные в какой-то форме. oauth2-proxy и Pomerium держат ни одного и делегируют выше по цепочке. Для тех, которые делают, резервную копию базы данных или файла конфигурации вместе с ключом тайны экземпляра, потому что восстановление без соответствующей тайны делает недействительным каждый сеанс и зарегистрированный второй фактор.