Аутентификация и авторизация

Домен аутентификации и авторизации охватывает все механизмы входа в 1Форму: от встроенной формы с логином и паролем до корпоративных протоколов LDAP, SAML, OAuth/OIDC и RADIUS. Архитектура построена на двух уровнях — сервисы подключения к внешним системам и провайдеры настроек входа, включая второй фактор и привязку к группам. После успешной аутентификации система выдаёт сессионный токен, а все входы фиксируются в журнале. Домен также включает политики паролей, защиту от подбора, персональные токены доступа (PAT), самостоятельную регистрацию и настройку страницы авторизации.

Обзор

Система аутентификации 1Формы поддерживает множество способов входа: от встроенной формы с логином/паролем до корпоративных протоколов (LDAP, SAML, OAuth/OIDC, RADIUS). Аутентификация построена на двухуровневой архитектуре: сервисы (подключение к внешним системам) и провайдеры (настройки входа, второй фактор, привязка к группам). Каждый провайдер ссылается на один сервис; для каждого сервиса допускается только один активный провайдер.

После успешной аутентификации система выдаёт сессионный токен. Срок его действия задаётся настройками 1Формы и не зависит от способа входа: при SAML и OIDC он такой же локальный, как при входе по паролю, и из ответа внешнего провайдера не берётся.

Все входы фиксируются в журнале входов; при успешном входе сбрасывается счётчик неудачных попыток. Выход из системы не логируется.

Начало работы и вход в систему

1Форма — веб-приложение, работа ведется в интернет-браузере, установка специального ПО не требуется. Для входа пользователь вводит в адресной строке браузера электронный адрес системы своей компании. Адрес выдается администратором; типовой вид — https://1forma.yourcompany.ru.

Учетные данные пользователя (логин и пароль) выдаются администратором тем способом, который допустим внутри компании: по E-mail, устно, в конверте и т.п. Самостоятельное восстановление учетных данных возможно только при Forms-авторизации.

Процедура входа зависит от того, настроена ли синхронизация с Active Directory: при настроенной синхронизации выполняется сквозная Windows-авторизация, без нее — Forms-авторизация с вводом логина и пароля.

Если в пароле учетной записи Active Directory символы < и > расположены в порядке < .. >, при входе возникает ошибка. Обратная последовательность > .. < обрабатывается корректно.

Способы входа на форме авторизации

Форма авторизации показывает пользователю один или несколько способов входа. Поддерживаются:

Способ	Что видит пользователь
Логин и пароль	Классический вход по учётным данным
По номеру телефона	Поле телефона → 4-значный SMS-код
По email	Поле email → 4-значный код на почту
Через внешнего провайдера	Отдельный экран с кнопками провайдеров (AD, SAML, OAuth и т.д.); форма логин/пароль скрыта, переход к ней по ссылке

Набор способов, способ по умолчанию, разрешена ли регистрация, для каких устройств виден каждый способ (веб / мобильный / все), ссылки на пользовательские соглашения и срок жизни кодов подтверждения настраивает администратор. Администратор также может полностью запретить вход по email (тогда пользователь может войти только по логину).

Подробности настройки — в admin.md § «Настройка типов входа» и admin.md § «Политики входа».

Провайдеры аутентификации и их параметры

Провайдер — основная сущность управления внешней аутентификацией. Поддерживаемые типы провайдеров: ActiveDirectory, SAML, OpenLDAP, Radius, OAuth. Каждый провайдер настраивается набором параметров:

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

Параметр	Назначение
Тип провайдера	Один из пяти поддерживаемых протоколов
Сервис аутентификации	Ссылка на ранее созданный сервис (одноименного типа)
По умолчанию	Провайдер отображается выбранным в списке «Вход в» на странице авторизации
Активен / Скрыт	Управление видимостью на странице авторизации
Ссылка для восстановления пароля	Кастомная ссылка вместо стандартной при нажатии «Забыли пароль?»
Второй фактор	Настройка MFA: нет / SMS / Email / Сервис (Multifactor) / Telegram
Группы	Ограничение доступа к провайдеру по группам пользователей

Если провайдер один — выпадающий список «Вход в» не показывается, аутентификация идет напрямую через 1Форму. При нескольких провайдерах без флага «По умолчанию» по умолчанию выбирается «Первая Форма» (встроенная аутентификация).

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

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

Второй фактор при сохранении провайдера. Если для провайдера выбран второй фактор Telegram, нужно указать идентификатор бота, а для второго фактора типа «сервис» — выбрать сервис второго фактора. Без этих полей провайдер не сохраняется, причина показывается в сообщении.

Ошибки аутентификации через AD и OpenLDAP фиксируются в журнале ошибок системы.

Встроенная аутентификация (Forms-авторизация)

Базовый механизм: пользователь вводит логин и пароль, система проверяет их в собственной базе. При включенной настройке «Брать пароль из AD» (общие настройки) пароль проверяется в Active Directory, но сам механизм формы остается Forms-авторизацией.

Для мобильных приложений доступна двухшаговая авторизация: после ввода пароля приходит SMS/push-код, подтверждение которого завершает аутентификацию.

На форме входа пользователь может выбрать язык интерфейса — по клику на иконку выбора языка раскрывается список доступных языков. Язык можно сменить и позднее, уже после входа в систему. Выбор, сделанный до входа, браузер запоминает и показывает при следующих открытиях формы входа; при входе он один раз переносится в профиль и из браузера снимается. Дальше язык интерфейса берётся из профиля (Users.LanguageID), поэтому обновление страницы язык не откатывает и смену языка, сделанную из другого клиента, не перезаписывает.

Восстановление пароля

Если пользователь не помнит логин и/или пароль и в компании используется Forms-авторизация, в окне авторизации он нажимает ссылку «Забыли пароль?» и в открывшемся окне выбирает один из трех способов восстановления.

Способ	Что вводит пользователь
По Email — «Получить код восстановления по Email»	E-mail и код безопасности с картинки (капча)
По SMS — «Получить код восстановления по SMS»	Номер телефона и капчу
По логину — «Получить код восстановления по логину»	Логин, выбор канала доставки кода (Email или SMS) и капчу

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

После заполнения полей пользователь нажимает кнопку Отправить — в течение нескольких минут код восстановления приходит на указанный адрес или номер (если код не получен, нужно обратиться к администратору). Затем открывается следующее окно восстановления — его также можно открыть сразу по ссылке «У меня есть код восстановления» на начальном окне. Поле E-mail или Телефон заполняется системой автоматически; пользователь вводит полученный код, нажимает Далее и регистрирует новый пароль.

Код восстановления — 6-значный, по умолчанию действует 5 минут и одноразовый: после успешного использования тот же код повторно не принимается. Если код просрочен, запросите новый.

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

При синхронизации с Active Directory для смены пароля дополнительно требуется ввод текущего пароля. При Windows-авторизации самостоятельная смена пароля невозможна — нужно обращаться к администратору.

Смена пароля при истечении срока

При истечении срока действия пароля при входе отображается форма смены пароля. Срок действия истекает в трех случаях:

1. Превышена сумма даты установки пароля и срока действия пароля из общих настроек.
2. При создании пользователя активирован флаг «Сменить пароль при входе».
3. Пользователь не входил в систему более 30 дней.

Под полем подтверждения пароля показывается надпись «Пароль не совпадает» (красным), если значения различаются; при совпадении становится активна кнопка Сохранить. После сохранения нового пароля система автоматически выполняет повторную авторизацию с обновленными учетными данными.

Аутентификация через Active Directory

Аутентификация через доменную инфраструктуру Microsoft. Требования: адрес домена, системная учётная запись, сервер приложений в домене (или DNS-зона на адаптере). Параметры сервиса: домен, признак корня леса, логин/пароль доступа к AD (опционально, если пользователь приложения имеет нужные права). Для лесов AD с одноимёнными учётными записями администратор может переключить режим работы с каталогом — подробности в admin.md § «Active Directory». При настроенной синхронизации с Active Directory выполняется сквозная Windows-авторизация: учетные данные для входа в Windows автоматически применяются и для входа в 1Форму, пользователю не нужно запоминать дополнительный логин и пароль. Вход через Active Directory возможен также по сертификату SSL.

В 1F Certificate Edition синхронизации с Active Directory в сборке нет, поэтому сквозная Windows-авторизация работает иначе: пользователь входит, только если его учётная запись уже заведена в 1Форме и находится по SID (либо по UPN при соответствующей настройке Negotiate). Новые пользователи из каталога не создаются, членство в группах при входе не синхронизируется; пользователь, которого нет в локальной базе, не входит. Настройка профилей синхронизации в такой сборке не влияет на вход.

Аутентификация через OpenLDAP и RADIUS

OpenLDAP обеспечивает аутентификацию через LDAP-каталог (не AD). Параметры подключения: адрес сервера, DN-путь, DN-привязки, пароль. SSL-подключение настраивается администратором — см. admin.md § «OpenLDAP».

RADIUS обеспечивает аутентификацию через RADIUS-сервер. Минимальная конфигурация: IP-адрес сервера, порт, shared secret. Оба протокола подходят для организаций, где нет инфраструктуры Active Directory, но есть централизованный каталог или RADIUS-сервер для сетевой аутентификации.

Аутентификация через SAML

Протокол SSO на основе XML-утверждений. Используется для интеграции с ADFS и другими SAML-провайдерами. Вся коммуникация между 1Формой и внешним провайдером проходит через браузер пользователя (запросы и перенаправления).

Что нужно для работы: настроенный сервис SAML на стороне 1Формы (метаданные IdP, сертификат для подписи, способ сопоставления пользователей) и зарегистрированная 1Форма как Service Provider у внешнего IdP. Поддерживается автосоздание учётных записей из атрибутов SAML — администратор задаёт правила сопоставления полей профиля.

Полная пошаговая настройка (включая параметры сервиса, генерацию сертификатов, регистрацию в IdP и маппинг атрибутов) — в admin.md § «SAML (ADFS)».

Аутентификация через OAuth 2.0 / OpenID Connect

Протокол аутентификации через внешний IdP (например, KeyCloak). Поддерживается стандартный поток авторизации OAuth 2.0 с получением ID-токена по OpenID Connect. Способы сопоставления пользователя с учётной записью 1Формы, которые может выбрать администратор:

• по справочнику (категории);
• по произвольному атрибуту профиля;
• по учётной записи внешнего сервиса;
• по никнейму;
• по SID.

Полная настройка сервиса OAuth/OIDC, регистрация провайдера и параметры маппинга — в admin.md § «OAuth / OIDC».

Если у пользователя нет лицензии на модуль «Первая форма» или используется конкурентная лицензия с исчерпанным лимитом сессий, OIDC-вход не выпускает токен и возвращает пользователя на страницу входа /entry/signin с GET-параметром authError, содержащим понятное сообщение об ошибке. Такое поведение унифицирует OIDC-вход с парольным: при парольной авторизации аналогичные ошибки лицензии уже отдавались с текстом, а не сырому 401.

Windows-аутентификация и первый вход

Поддерживается прозрачная аутентификация через Windows. При настроенной синхронизации с Active Directory учетные данные для входа в Windows автоматически применяются и для входа в 1Форму — пользователю не нужно запоминать дополнительный логин и пароль. Вход через Active Directory возможен также по сертификату SSL.

Для первого входа пользователь после загрузки рабочего стола Windows выбирает ярлык приложения (если он создан) или вводит адрес приложения в браузере. Если в компании требуется согласие на обработку персональных данных, при первом входе показывается экран с текстом соглашения — пользователь включает параметр «Предоставляю согласие...» и нажимает кнопку ОК.

В общих настройках приложения существует параметр «Страница редиректа несуществующих пользователей» — применяется только для Windows-аутентификации.

В 1F Certificate Edition поведение первого входа отличается: обращения к каталогу не выполняются, учётная запись создаётся только вручную администратором, синхронизация членства при входе не происходит.

Многофакторная аутентификация (MFA)

Второй фактор настраивается на уровне провайдера аутентификации. Поддерживаются четыре метода: SMS, Email, внешний сервис Multifactor и Telegram. Каждый метод требует предварительной настройки соответствующего провайдера или бота и выдачи специального права группе пользователей.

SMS. Специальное право группы «Подтверждение пароля по SMS (при входе)». На мобильный номер из профиля отправляется 5-значный код. Требуется настроенный SMS-провайдер. Также доступно право «Подтверждение пароля по SMS (при смене)» — для подтверждения смены пароля.

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

Если номер не подтверждён, вход по одному паролю не завершается: код на такой номер не отправляется, а клиент получает отказ с признаком «нужно подтвердить телефон». Подтвердить номер можно по коду из SMS, не входя в систему: запрос кода защищён капчей, повторная отправка возможна не чаще одного сообщения в минуту, код действует 15 минут. Интерфейс входа этот признак не обрабатывает, поэтому в самом сценарии входа номер не подтвердить — его подтверждают в профиле пользователя. Правило действует на обоих входах по логину и паролю — и в веб-интерфейсе, и в мобильном приложении.

Какая настройка решает, зависит от того, известен ли провайдер, которым подтверждены учётные данные. Если креды подтвердил конкретный провайдер, в том числе встроенный, неподтверждённый номер оценивается по второму фактору этого провайдера, а глобальная настройка двухэтапной авторизации не учитывается; глобальная настройка применяется там, где провайдер не определён, — при входе по номеру телефона и при проверке PIN. Право «Подтверждение пароля по SMS (при входе)» нужно и в том, и в другом случае. Поэтому один и тот же пользователь с одним и тем же набором настроек получает на веб-входе и на мобильном входе один исход: либо токен, либо отказ с признаком «нужно подтвердить телефон».

Email. Специальное право группы «Двухфакторная аутентификация по Email». На почтовый адрес из профиля отправляется цифровой код. Требуется настроенный SMTP и почтовый ящик для системных писем.

Multifactor (сервис). Интеграция с внешней системой MULTIFACTOR (с версии 2.256). Процесс: пользователь вводит логин/пароль, при успехе система запрашивает MULTIFACTOR, пользователя перенаправляют на страницу второго фактора (мобильное приложение, пуш, голосовой звонок и т.п.), после подтверждения возвращается на 1Форму и попадает в систему. Если метод выключен в настройках или провайдер аутентификации неактивен, второй фактор через этот сервис не выполняется: и запрос на вход, и возврат от сервиса завершаются отказом, вход мимо второго фактора не проходит. Полная настройка (создание сервиса, регистрация в кабинете MULTIFACTOR, конфигурация сертификата) — в admin.md § «Multifactor».

Проверка ответа сервиса MULTIFACTOR. После подтверждения второго фактора сервис возвращает пользователя в 1Форму с подписанным токеном. Вход завершается, только если подпись токена верна и в нём указаны логин, адрес возврата, срок действия и время выпуска. Токен с истёкшим или ещё не наступившим сроком действия либо выпущенный больше 5 минут назад не принимается; на расхождение часов сервера 1Формы и сервиса отводится 30 секунд. Если токен не прошёл проверку, сессия не создаётся: пользователь возвращается на страницу входа без пояснения причины и проходит вход заново.

Telegram. Специальное право группы «Двухфакторная аутентификация через Telegram». Требуется настроенный Telegram-бот. Процесс: после ввода логина/пароля пользователя перенаправляют в Telegram для подтверждения; после подтверждения он возвращается в 1Форму уже залогиненным. Настройка: администратор создаёт бота в Telegram (через стандартный @BotFather), регистрирует его реквизиты в сервисе аутентификации 1Формы и выдаёт спецправо группе. Подробности — в admin.md.

Ввод кода на форме входа. Для методов с одноразовым кодом после проверки логина и пароля (или входа по номеру телефона) поверх формы входа открывается окно «Подтверждение входа» с подсказкой «Введите код из сообщения». В нём поле «Введите код», кнопка «Вход» для завершения входа и «Отмена» для возврата к форме. Запросить код заново можно кнопкой «Запросить снова»: минуту после отправки она заблокирована и показывает обратный отсчёт — «Запросить через N». После верного кода пользователь попадает в систему.

Неверный или просроченный код. Если введённый код не подошёл или истёк, окно «Подтверждение входа» остаётся открытым и показывает сообщение об ошибке от сервера — раньше нажатие просто ничего не давало. Вход при этом не выполняется, а код можно запросить заново и ввести ещё раз.

Политики паролей для веб-входа

Настройки в разделе «Настройки требований к паролям» общих настроек:

Параметр	Описание
Срок действия пароля (дни)	При истечении — принудительное перенаправление на форму смены (только Forms-авторизация)
Минимальная / Максимальная длина	Ограничения длины
Спец. символ обязателен	Минимум один символ, не являющийся буквой/цифрой
Заглавная буква обязательна	Минимум одна прописная буква
Запрет совпадения с предыдущим	Блокировка повторного использования паролей
Запрет совпадения с логином	По умолчанию разрешено, можно запретить
Длина истории паролей	Количество запоминаемых предыдущих паролей
Проверка на дату рождения	Запрет паролей, содержащих дату рождения
Минимальная длина последовательности	Обнаружение клавиатурных (qwerty, йцукен) и алфавитных последовательностей
Минимальная длина повторяющегося паттерна	Обнаружение повторений типа «qweqwe»

Срок действия кода для восстановления пароля настраивается отдельно (в днях).

Пароли для самостоятельной регистрации

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

Полный перечень настраиваемых полей и пример конфигурации — в admin.md § «Самостоятельная регистрация».

Мобильные политики паролей и восстановление

Дополнительный пароль для входа в мобильное приложение, задается для групп:

• Пароль не обязателен
• 4 цифры
• 6 цифр
• Буквенно-цифровой (с регулярным выражением)

При пересечении групп с разными политиками действует наиболее строгая. Специальное право «Запрещено пользоваться восстановлением пароля» блокирует самостоятельное восстановление пароля для группы пользователей, которым назначена данная политика. Это право применяется независимо от типа мобильной политики и распространяется как на Forms-авторизацию, так и на вход через внешних провайдеров.

Защита от подбора и блокировки

Общие настройки приложения содержат три параметра защиты:

Параметр	Действие
Максимальное число попыток логина до блокировки	Полная блокировка учетной записи (разблокировка — через администратора)
Максимальное число попыток логина пользователя до капчи	Капча после N неудачных попыток для конкретного пользователя
Максимальное число попыток логина с IP до капчи	Капча/блокировка IP после N неудачных попыток с одного адреса

При работе через балансировщик нагрузки администратор должен настроить проброс реальных IP клиентов с прокси/балансировщика — иначе счётчик попыток «с одного IP» увидит только адрес самого балансировщика и заблокирует всех пользователей сразу. Настройка — в admin.md § «Защита от брутфорса».

Белый список IP-адресов (UserWhiteIp). Механизм, снимающий IP-ветку капчи для конкретной пары «пользователь + IP»: если адрес пользователя есть в белом списке, капча по IP для него не запрашивается, при этом порог MaxUserLoginAttempsCountBeforeCaptcha продолжает действовать. Заполняется автоматически — при входе по коду из письма или SMS и при восстановлении пароля по коду (метод GuardIpPassed с условием user != null); при обычном входе логином/паролем IP в белый список не попадает. Отдельного интерфейса управления нет. Таблица: UserWhiteIp (UserId int, Ip binary(4)).

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

Геолокация при входе: по умолчанию запрашивается при каждом первом входе. Настройка «Запрашивать геолокацию только после неудачного логина» ограничивает запрос только случаями неудачных попыток.

Отзыв именной лицензии во время сессии

С версии 2.268.329 отзыв именной лицензии у уже авторизованного пользователя вступает в силу в течение минуты, а не «висит» до конца жизни access-токена (раньше — до ~5 часов). Логика:

• В активной сессии система раз в минуту перепроверяет именную лицензию пользователя. Между перепроверками доступ сохраняется по выданному ранее токену — это сделано осознанно, чтобы перепроверка не нагружала каждый запрос.
• Если на момент очередной перепроверки лицензии уже нет, ближайший запрос пользователя получает отказ (HTTP 402), а веб-клиент редиректит на страницу входа (обработка 402 в Auth401Interceptor — с 2.268.338; до этой версии браузер «зависал в вечной загрузке»). Войти снова без лицензии нельзя — на форме логина уже работает обычная проверка лицензий.
• Отказ фиксируется в журнале действий (ActionLog) с указанием причины, идентификатора пользователя, IP и хоста — чтобы администратор мог отследить факт обрыва сессии по лицензии.
• Сценарий перевоплощения (impersonation) и support-аккаунты не затронуты: support-аккаунты доступ сохраняют, перевоплощение работает по правилам своей задачи.
• Пользователи с действующей лицензией продолжают работу без прерываний — перепроверка обновляет внутренний таймер при каждом успешном гранте.

Интервал перепроверки (1 минута) в конфигурацию не выносится — этого достаточно, чтобы отзыв вступал в силу за минуты, а не часы, и при этом перепроверка не нагружала per-request путь.

Самостоятельная регистрация

Самостоятельная регистрация пользователей включается администратором: задаётся набор полей формы и допустимые способы (по телефону / по email / по нику).

Правила автозаполнения: - одно из полей «Телефон», «Email» или «Ник» — обязательно; - при заполнении ника обязателен и пароль; - если ник не указан — система автозаполняет его из телефона или email; - если не указано отображаемое имя — оно собирается из «Имя Фамилия» или ника; - при регистрации по телефону или почте поле-источник автоматически заполняется и скрывается.

Администратор может настроить регистрационную ссылку с предзаполненными значениями — пользователь переходит по ней и попадает на форму с уже заполненными полями. Полная настройка — в admin.md § «Самостоятельная регистрация».

Процесс регистрации

Регистрация проходит по шагам:

1. На форме авторизации — кнопка «Регистрация».
2. Выбор способа верификации: по номеру телефона или по email.
3. Валидация ввода:
4. Email — проверка стандартного формата (@, доменная часть). При ошибке: «Введите Email».
5. Телефон — ввод по маске с ведущим знаком «+»: разделители система подставляет сама, пример формата +7 (999) 123-45-67 показан в пустом поле и подсказкой под ним. Перед отправкой номер приводится к цифрам с ведущим «+». При ошибке: «Введите телефон».
6. Кнопка Далее → ввод полученного кода (SMS или email).
7. Дальше:
8. Если пользователь уже был зарегистрирован — перенаправление на стартовую страницу.
9. Если пользователь новый — форма регистрации с обязательными полями (набор настраивается администратором).

Ввод номера телефона

Поле «Телефон» при регистрации — и на шаге подтверждения номера, и в форме заполнения данных — заполняется по маске: ведущий знак + и разделители система подставляет сама, пользователь вводит только цифры. Пример формата +7 (999) 123-45-67 показан дважды: в пустом поле и подсказкой под ним.

Номер можно вводить и вставлять из буфера в любом виде — с восьмёркой вместо кода страны, с пробелами, скобками и дефисами. Перед отправкой система приводит номер к единому виду: только цифры с ведущим знаком «+», а номер, начинающийся с 8, отправляется как +7…. Поэтому номер, набранный с разделителями, и номер, скопированный из другого сервиса, обрабатываются одинаково.

Проверка идёт по числу цифр — их должно быть не меньше одиннадцати. Если цифр меньше, под полем появляется сообщение «Введите телефон». Дальше работают обычные шаги регистрации: код подтверждения приходит по SMS на этот номер.

Требования к паролю и расширенная политика безопасности при регистрации

Требования отображаются при фокусе на поле пароля: серым до ввода, красным при невыполнении, зелёным при выполнении. Подтверждение пароля имеет онлайн-индикацию: «Пароль не совпадает» (красным) / «Пароль совпадает» (зелёным). Редактирование любого из двух полей запускает повторную проверку. Кнопка «Регистрация» на финальном шаге активна только когда все обязательные поля заполнены корректно.

Администратор может включить дополнительные правила проверки сложности: запрет простых последовательностей (идущие подряд буквы/цифры), запрет повторения одинаковых фрагментов, запрет связи с персональными данными (логин, дата рождения), минимальное отличие от ранее использованных паролей.

SSO (Single Sign-On)

SSO позволяет один раз войти во внешнюю систему (Active Directory, ADFS, KeyCloak) и автоматически попадать в 1Форму без повторного ввода логина и пароля. Поддерживаемые протоколы — SAML и OAuth/OpenID Connect.

Пользовательский сценарий простой: на форме входа отображается кнопка с названием провайдера, по клику пользователь перенаправляется во внешнюю систему, проходит там аутентификацию, и возвращается в 1Форму уже залогиненным. При нажатии «Выйти» система не только закрывает локальную сессию, но и сообщает внешнему провайдеру о выходе — чтобы при следующем входе провайдер заново запросил пароль.

Возврат на исходную страницу при входе через внешнего провайдера

Если пользователь переходит по прямой ссылке на задачу или другую страницу системы, не будучи авторизованным, SPA сохраняет исходный URL и редиректит его на форму входа. После входа через SAML (ADFS) система возвращает пользователя на исходную страницу, а не на главную. На OAuth-провайдерах поведение зависит от того, как бэк переносит returnUrl через state — нужна отдельная проверка для каждого провайдера. При обычном входе по логину и паролю возврат на исходную страницу работает через SPA-логику и описанным фиксом не затрагивается.

Сертифицированный режим входа (ФСТЭК-сборка)

В сертифицированной сборке 1Формы (barebone, режим ФСТЭК УД4) набор каналов входа ограничен сертифицируемыми. Доступны:

• Вход по логину и паролю — встроенная аутентификация 1Формы (POST /api/auth/token-v2) с той же парольной политикой, что и в полной сборке; пароль меняется через POST /api/user/change-password. Второй фактор к этому входу не применяется: признак включённого второго фактора у пользователя на вход не влияет.
• Kerberos / Negotiate — Windows-аутентификация, в том числе со средствами защиты информации на АРМ (SecurLogon, JaCarta, Рутокен Логон).
• OIDC и SAML — вход через внешних провайдеров идентификации (например, Blitz, Avanpost FAM, RooX UIDM); 1Форма выступает доверяющей стороной, а проверку учётных данных выполняет внешний провайдер.

SAML-сессия в сертифицированной сборке продлевается тем же механизмом, что и в полной; способ задаётся режимом продления провайдера. В режиме по умолчанию (IdentityProvider) веб-интерфейс сессию не продлевает — по истечении токена пользователь проходит интерактивный вход; в режиме Activity вход продлевается, пока пользователь работает, в пределах абсолютного потолка. Механика продления и её настройка — в admin.md § «SAML (ADFS)».

Выход из системы при входе по логину и паролю и при Windows-аутентификации выполняется обращением POST /app/v1.0/api/Logoff: сервер удаляет запись сеанса пользователя и аннулирует cookie сеанса. При входе через SAML и OIDC выход выполняется на стороне провайдера: GET /api/auth/saml/logout и GET /api/auth/oauth/logout.

Восстановление пароля, самостоятельная регистрация, вход по коду подтверждения, мобильный вход (api/auth/mobile/info), провайдеры ActiveDirectory, OpenLDAP и RADIUS, Basic-аутентификация и персональные токены доступа (PAT) в этой сборке не поддерживаются: соответствующие каналы входа возвращают 404. Второй фактор через сервис MULTIFACTOR (маршруты api/multifactor/*) в этой сборке тоже недоступен: модуль интеграции с сервисом и клиент RADIUS в её состав не входят. Политика входа по умолчанию (JWT + Negotiate) и админ-настройка внешних OAuth/SAML-провайдеров сохранены.

Режим перевоплощения

Администраторы по умолчанию имеют доступ к перевоплощению — работе в системе от имени другого пользователя. Спецправо «Запретить перевоплощение» блокирует перевоплощение для группы; запрещено назначать группе «Администраторы». Администратор с этим правом не может деактивировать его и редактировать состав своей группы. Право не переходит заместителю в период замещения. Удаление из группы с этим правом через смарт-действие «Удалить пользователя из групп» запрещено. Перевод в группу без этого права возможен только администратором, у которого право на перевоплощение сохранено.

Персональные токены доступа (PAT)

PAT — долгоживущие интеграционные токены для безопасного доступа к API без логина/пароля. Предназначены для автоматизации и внешних интеграций. Право на создание токенов зависит от роли: группе можно выдать спецправо «Генерация PAT», администраторы получают эту возможность по умолчанию и могут выдавать PAT любому пользователю, обычные пользователи без спецправа могут просматривать и отзывать свои токены, но не генерировать новые.

Токен показывается единожды и в системе не хранится в открытом виде: при генерации полная строка токена показывается пользователю один раз — в системе сохраняется только защищённая контрольная сумма, восстановить токен невозможно. Пользователь обязан сохранить строку токена самостоятельно; повторно получить её нельзя. Токен передаётся в HTTP-заголовке 1F-Pat при вызове API. Технические детали транспорта (в т.ч. для realtime-подключений) — в admin.md § «Аутентификация API-запросов». Пользователь, аутентифицированный через PAT, работает с теми же правами, лицензиями и ограничениями, что и при входе по логину/паролю. Рекомендация: выдавать PAT на специального сервисного пользователя в отдельной группе с ограниченными правами.

Администратор может задать максимальное число активных токенов на пользователя и максимальный срок жизни токена. По умолчанию — 10 токенов и 365 дней. Подробности — в admin.md § «Personal Access Tokens».

Интерфейс управления токенами

Доступ — через раздел «Ключи доступа» в персональном меню пользователя (сразу после пункта «Канбан») → пункт «Токены». Раздел виден только пользователям, чьей группе выдано спецправо «Генерация PAT»; статус администратора сам по себе доступа не даёт. Токен можно выпустить только себе — сгенерировать PAT за другого пользователя нельзя даже администратору.

Интерфейс страницы:

• Заголовок «Токены доступа» с фильтром по статусу (по умолчанию — «Активные»).
• Кнопка «+ Создать токен» в правом верхнем углу.
• Таблица столбцов: Название, Токен (маскированный, виден префикс + ****), Статус (Активен/Отозван/Истёк), Активен до, Дата создания, Отозвать (×).
• Пустая таблица показывает «Нет данных».

Создание токена:

1. Кнопка + Создать токен → модальное окно «Создание токена».
2. Поля: Название (произвольное), Срок действия (по умолчанию — настроенный администратором максимум).
3. Кнопка Создать (или Отмена).
4. Открывается диалог «Токен создан»: предупреждение на жёлтом фоне (токен виден один раз), скрытое значение токена (раскрывается иконкой глаза), кнопка копирования.
5. После закрытия диалога новая запись появляется в таблице.

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

Отзыв токена: кнопка × в колонке «Отозвать» — токен перестаёт работать сразу.

Текущие ограничения PAT

У текущей реализации персональных токенов доступа есть несколько ограничений:

• Области действия (scopes) не реализованы — все токены работают с полным набором прав пользователя.
• Логирование входов по PAT — отдельной записи о входе по PAT в журнале нет; фиксируются только дата и IP последнего использования у самого токена.
• Очистка просроченных или отозванных токенов не автоматизирована — записи остаются в системе как история.

MCP-имперсонация (перевоплощение через MCP)

С версии 2.268.356 (задача #2096971, коммит 5a199942fb) PAT-токены поддерживают имперсонацию при работе через MCP-интерфейс (Model Context Protocol). Это позволяет внешнему AI-агенту, подключённому по MCP, выполнять действия от имени другого пользователя, используя PAT владельца интеграции.

Как это работает:

• Имперсонация активируется только на маршрутах /mcp* (проверка StartsWith("/mcp", StringComparison.OrdinalIgnoreCase)).
• В запросе должен быть заголовок 1f-real-user-id с UserId целевого пользователя (того, от имени которого выполняется действие).
• Владелец PAT (тот, чей токен используется) становится OldUserId — это сохраняется для аудит-трэйла.
• В контексте запроса UserId подменяется на таргет, OldUserId фиксирует владельца PAT.

Правила и ограничения (fail-closed):

• Только MCP — на обычных API-маршрутах заголовок 1f-real-user-id игнорируется.
• Fail-closed — если имперсонация не удалась (нет прав, пользователь не найден, попытка эскалации), запрос отклоняется с ошибкой аутентификации (401). Нет фоллбэка на владельца PAT.
• Анти-эскалация — встроенная проверка права на имперсонацию:
• god (администратор платформы) → может имперсонировать кого угодно;
• non-god → никогда не может имперсонировать god;
• остальные пары → требуется спецправо group-on-group Impersonate (то же право, что и для обычного перевоплощения через UI, см. раздел «Режим перевоплощения»). Специальных прав под MCP не вводилось.
• Цепочечная имперсонация запрещена — OldUserId всегда указывает на владельца PAT, нельзя «перепрыгнуть» дальше.
• Аудит — пара UserId (таргет) / OldUserId (владелец PAT) доступна в логах и ActionLog для отслеживания, кто и от чьего имени действовал.

Рекомендация: для MCP-интеграций заводите отдельного сервисного пользователя с PAT и минимально необходимыми правами, выдавайте группе этого пользователя спецправо Impersonate на целевые группы.

Мои секреты (self-service secrets)

Помимо персональных токенов доступа (PAT), пользователь может самостоятельно создавать секреты для внешних интеграций — без обращения к администратору. Секреты доступны в разделе «Ключи доступа» боковой панели: подменю «Секреты».

В отличие от PAT, которые используются для доступа к API 1Формы, секреты предназначены для хранения учётных данных внешних сервисов — логинов, паролей, API-ключей, токенов. Например, токен для внешнего API или бота, которым пользуется только сам сотрудник.

Типы секретов

При создании секрета пользователь выбирает один из двух типов (контрактов):

• Токен (token) — секрет с фиксированным набором полей, определённым контрактом. Подходит для большинства интеграций, где нужен один токен или ключ.
• Произвольный (custom) — секрет со свободным набором полей. Пользователь сам добавляет нужные пары «ключ → значение» через редактор. Подходит, когда стандартный контракт не покрывает нужные поля.

Создание секрета

1. Откройте боковую панель, нажмите «Ключи доступа» и выберите «Секреты».
2. Нажмите кнопку «Создать секрет».
3. Выберите тип секрета — «Токен» или «Произвольный».
4. Заполните название и параметры ключа (для «Токена» — значение вводится в скрытом поле; для «Произвольного» — добавьте нужные поля через редактор key-value).
5. Нажмите «Сохранить».

Важно: значение секрета после сохранения не отображается — ни в списке, ни при редактировании. Изменить его можно только полной перезаписью.

Редактирование и удаление

При редактировании можно изменить только название и значение — тип секрета и параметры ключа заблокированы (для смены создайте новый секрет). Удаление — через контекстное меню строки, с подтверждением; секрет деактивируется, запись остаётся в журнале аудита.

Ограничения

Пользователь видит и может управлять только своими секретами. Чужие и административные секреты через этот раздел недоступны; при попытке доступа к чужому секрету система показывает отказ в доступе, а не «не найдено».

Согласие на обработку персональных данных

При включённой настройке «Требовать подтверждение согласия на обработку перс. данных» (общие настройки) система при входе проверяет, давал ли пользователь согласие. Если согласие требуется и пользователь его ещё не давал — в новом SPA открывается блокирующее окно с текстом соглашения. Окно нельзя закрыть крестиком, клавишей Escape или кликом по фону: пользователь должен выбрать одно из двух действий.

• Подтвердить — согласие сохраняется в карточке пользователя, окно закрывается, работа продолжается. При следующем входе окно уже не отображается, пока администратор не запросит повторное подтверждение.
• Отклонить — система выполняет logout и возвращает пользователя на страницу входа.

Окно согласия не показывается:

• в режиме перевоплощения (impersonation);
• сервисным учётным записям (Users.IsService = 1);
• системному пользователю (UserId = 3).

С версии 2.268.339 согласие собирается нативно в SPA через PersonalDataConsentService + personal-data-consent.component; запуск — из post-bootstrap.service.ts после загрузки приложения, проверка идёт по уже загруженным данным пользователя и конфигурации, без дополнительных GET-запросов. До 2.268.339 SPA редиректил на legacy-aspx страницу для сбора согласия.

Управление со стороны администратора. Согласие хранится в карточке пользователя (Users.IsAgreeToStorePersonalData). Администратор может запросить его повторное подтверждение: - у конкретного пользователя — действие «Запросить согласие на обработку персональных данных повторно» в карточке пользователя AdminSPA (вкладка профиля, блок служебных действий) — с 2.268.339; - массово у всех пользователей — кнопка остаётся на legacy-aspx странице общих настроек приложения (UI чекбокса требования согласия и текст соглашения тоже там).

Безопасность транспорта и кастомизация страницы авторизации

Соединение с системой защищено на транспортном уровне. Принудительный HTTPS — все обращения по незащищённому HTTP автоматически перенаправляются на HTTPS. HSTS — браузеру предписывается всегда обращаться к сайту только по HTTPS, даже если пользователь набрал адрес без протокола. ⚠️ Настройка HSTS необратимая: после включения отключить её невозможно до истечения срока, заданного в политике.

Внешний вид страницы входа можно оформить под компанию:

Элемент	Настройка
Логотип	Загрузка файла (239x57 px, предпочтительно PNG)
Фоновое изображение	Путь к файлу (2000x3000 px, предпочтительно SVG)
Текст под логотипом	«Текст на странице логина»

Связи с другими доменами

Аутентификация связана с несколькими смежными доменами:

Домен	Связь
Пользователи и группы	Провайдеры привязываются к группам; спецправа управляют MFA и восстановлением пароля; мобильные политики назначаются группам
Синхронизация (AD/1C)	Синхронизация учётных записей из AD и 1С; SAML-автосоздание профилей из атрибутов
Уведомления	SMS-провайдеры для MFA; email для кодов и восстановления пароля
Порталы	Стартовая страница после входа может быть порталом
Календарь / Exchange	Синхронизация с Exchange использует доменную авторизацию и перевоплощение
Чаты / Telegram	Telegram-бот для двухфакторной аутентификации
Смарт-логика	Глобальное смарт-событие «После создания пользователя» при регистрации
Журналы	Журнал входов, белый список IP-адресов, журнал ошибок аутентификации