---
title: "Создание первого администратора | FoxAuth"
description: "Одноразовый экран настройки, как устроен вход администраторов и второй фактор, который нужно включить в первую очередь."
canonical: "https://foxauth.dev/ru/docs/get-started/first-admin/"
lastmod: "2026-10-12T23:12:26+03:00"
---
Создание первого администратора

Сервер администрирует сам себя. Нет ни заранее созданного пароля, который нужно искать в логе, ни
команды create-admin: первый администратор создаётся из браузера, один раз.

Откройте /admin в только что подготовленном развёртывании, например
http://localhost:3000/admin.

Экран Create the first super admin запрашивает адрес e-mail и пароль длиной не менее
двенадцати символов. Учётная запись попадает в зарезервированный бакет пользователей
«Administrators», становится членом группы Super administrators — группы, члены которой
администрируют весь экземпляр, — и получает личную группу, как любой другой администратор.

Отправьте форму, затем войдите с этими учётными данными.

Маршрут настройки закрывается, как только в Super administrators появляется активный член, и с этого
момента отвечает 409 already_initialized. /admin становится страницей входа. Следующие
администраторы создаются в консоли на странице Administrators кнопкой New administrator, с
адресом e-mail и паролем не короче двенадцати символов. Суперадминистратор может также открыть
регистрацию на вкладке Sign-in этой страницы, чтобы люди регистрировались сами, или подключить
провайдера идентификации вашей организации в разделе Identity providers. Новый администратор
никогда не становится суперадминистратором, каким бы путём он ни появился: это право суперадминистратор
выдаёт отдельно, пунктом Make super administrator… в меню учётной записи. (Членство в обычной группе,
в свою очередь, предлагается приглашением по e-mail.) Если вы видите экран настройки в развёртывании, где
администраторы должны быть, это стоит расследовать: значит, в коллекции учётных записей, которую читает
этот сервер, их нет.

Осторожно

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

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

Администраторы входят через собственный issuer этого сервераЗаголовок раздела «Администраторы входят через собственный issuer этого сервера»

Вход в консоль — это поток authorization code OpenID Connect к тому самому серверу, который консоль
администрирует, через собственный (first-party) клиент admin-panel, который создаёт db:setup. Нет ни
второго хранилища паролей, ни отдельного пути аутентификации только для администраторов: администратор —
это конечный пользователь в зарезервированном бакете администраторов, а то, что admin API позволяет ему
делать, следует из групп, в которых он состоит.

Отсюда два следствия, и оба встречаются на практике:

Redirect URI клиента из начальных данных — $ISSUER/admin/callback; он записывается один раз, при
первой вставке клиента. Если ISSUER изменился после начального заполнения, вход перенаправляет на
URI, которого у клиента нет, и завершается ошибкой; повторный запуск db:setup этого не исправляет.
Что делать, см. в предупреждении в руководстве по Compose.

Без начальных данных консоль недоступна. Если db:setup ни разу не запускался, /admin/login
перенаправляет на /auth с client_id, которому не соответствует ни один клиент.

Включите второй факторЗаголовок раздела «Включите второй фактор»

Бакет администраторов — это дверь с паролем в публичном интернете, поэтому мы советуем первым делом
потребовать на нём приложение-аутентификатор. В консоли перейдите на страницу Administrators
(только для суперадминистраторов), откройте вкладку Sign-in, включите Require an authenticator
app for password sign-in и сохраните. Сначала консоль покажет, у скольких администраторов ещё нет
аутентификатора, и попросит подтвердить.

После этого для входа нужен шестизначный код в дополнение к паролю. Включение никого не блокирует:
администраторы без аутентификатора подключат его при следующем входе. Это касается и агента, который
входит через зарезервированный клиент admin-mcp, создаваемый database/mongodb.ts, — он проходит
через ту же дверь. Администраторы, которые входят через провайдера идентификации, вместо этого
проходят второй фактор этого провайдера: требование касается только входа по паролю.

Это важнее, чем может показаться. Неудачные попытки ввода пароля считаются по паре «бакет и адрес
e-mail», и адрес, достигший лимита, на какое-то время получает отказ. Бакет, требующий одноразовый код,
остаётся на первом окне блокировки, сколько бы раз она ни срабатывала, — так задумано: угаданный пароль
там никого не впускает. Кроме того, у администраторов нет самостоятельного сброса пароля, которым можно
было бы обойти блокировку. По-настоящему прочной эту дверь делает второй фактор, а не троттлинг.
Собственные настройки троттлинга — loginThrottle.failureCap, loginThrottle.windowSeconds и
loginThrottle.windowCeilingSeconds в справочнике настроек.

Что доступно администраторуЗаголовок раздела «Что доступно администратору»

Суперадминистраторская часть консоли охватывает сам экземпляр: настройки сервера, ключи подписи, SMTP,
учётные записи администраторов и хранилище сбоев. Быть суперадминистратором — значит состоять в
зарезервированной группе Super administrators; членство выдаётся и отзывается отдельными
операциями (Make super administrator… и Withdraw super administration… на странице
Administrators или admin_super_grant и admin_super_withdraw для агента), а последнего активного члена нельзя ни исключить, ни деактивировать. Любой другой
администратор создаёт проекты, бакеты и группы, приглашает людей в свои обычные группы по e-mail и читает
журнал аудита и страницу Usage своих групп. Владение определяется группой: доступ к контейнеру даёт членство в группе, которой
он принадлежит.

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

Если вы нашли проблему безопасности, а не конфигурации, политика раскрытия уязвимостей и контакты
проекта находятся на странице безопасности.

ПредыдущаяЗапуск из исходного кодаСледующаяРегистрация первого клиента