Аутентификация и доступ

Как работает вход, как хранятся пароли и токены, как проверяются права и какие адреса доступны без авторизации.

Вход

Вход по логину и паролю. Учётные записи локальные, хранятся в самой платформе.

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

Пароли

Пароли хранятся в виде bcrypt-хеша. Требований к сложности на стороне сервера нет. Интерфейс требует не меньше 4 символов при входе и не меньше 6 символов при смене пароля.

Токен сессии

Свойство	Значение
Как формируется	32 случайных байта в кодировке base64url
Как хранится на сервере	Только хеш sha256, сам токен в базе не лежит
Время жизни	SESSION_TTL_DAYS, по умолчанию 14 дней
Продление	Нет. Ни обновления, ни скользящего срока, ни ротации
Как передаётся	Заголовок Authorization: Bearer, либо параметр запроса token
Где хранится в браузере	localStorage

Куки для авторизации не используются.

Выход из системы помечает сессию отозванной. Запрос выхода всегда отвечает успехом, даже без токена.

Проверка на каждом запросе

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

Если пользователь получил ответ «не авторизован», интерфейс очищает токен и возвращает на страницу входа. Ответ «нет прав» из системы не выкидывает.

Права

Права описываются парами «действие и объект». Роль это набор таких пар. Пользователь принадлежит одной роли.

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

Ключи API

Ключи API это отдельный способ авторизации для внешних приложений. Ключ выдаётся от имени пользователя.

Особенности ключей

У ключа нет срока действия. Отдельных областей доступа тоже нет, кроме списка серверов MCP, через которые ключу разрешено работать. Ключ, выданный администратором, может обращаться ко всем управляющим адресам платформы от его имени.

Служебные учётные записи

С появлением внешних агентов у учётной записи есть вид: человек или служебная.

Свойство	Служебная учётная запись
Вход по паролю	Невозможен
Способ авторизации	Только ключ API
Показ в общем списке пользователей	Отсутствует
Для чего создаётся	Чтобы внешний агент обращался к платформе от своего имени

Такая запись создаётся платформой при выдаче модели внешнему агенту. Подробности на странице Внешние агенты.

Чего в платформе нет

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

Адреса без авторизации

Адрес	Как защищён
GET /healthz	Не защищён, отдаёт только состояние сервисов
POST /api/auth/login, POST /api/auth/logout	Не защищены по назначению
/api/chat-s3/**	Временный ключ в параметре запроса
Предпросмотр файлов чата	Временный ключ в адресе
Адреса ONLYOFFICE	Временный ключ, либо только флаг включения для проксирования
Всё на Runtime, включая /internal/*	Ничем. Только закрытая сеть
POST /internal/pii/mask на API	Подпись, привязанная к чату

Обязательное требование к развёртыванию

Runtime и внутренние адреса маскирования не должны быть доступны из интернета. Их защита это сетевые ограничения, а не авторизация.