Аутентификация и авторизация¶
Обзор¶
Система аутентификации 1Формы поддерживает множество способов входа: от встроенной формы с логином/паролем до корпоративных протоколов (LDAP, SAML, OAuth/OIDC, RADIUS). Аутентификация построена на двухуровневой архитектуре: сервисы (подключение к внешним системам) и провайдеры (настройки входа, второй фактор, привязка к группам). Каждый провайдер ссылается на один сервис; для каждого сервиса допускается только один активный провайдер.
После успешной аутентификации система выдаёт сессионный токен. При входе через SAML или OIDC срок его действия определяется ответом внешнего провайдера.
Все входы фиксируются в журнале входов; при успешном входе сбрасывается счётчик неудачных попыток и IP добавляется в белый список. Выход из системы не логируется.
Начало работы и вход в систему¶
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Форму. При нескольких провайдерах без флага «По умолчанию» по умолчанию выбирается «Первая Форма» (встроенная аутентификация).
Доменная фильтрация провайдеров. Список провайдеров на форме входа фильтруется по текущему домену страницы. Если для провайдера не задан ни один домен, он отображается на всех доменах. Если домены заданы, провайдер показывается только тогда, когда текущий домен страницы входа совпадает хотя бы с одним значением из списка. Это позволяет настроить разные наборы провайдеров для разных доменов входа в одной системе.
Ошибки аутентификации через AD и OpenLDAP фиксируются в журнале ошибок системы.
Типы аутентификации (провайдеры)¶
Встроенная (Forms-авторизация)¶
Базовый механизм: пользователь вводит логин и пароль, система проверяет их в собственной базе. При включенной настройке «Брать пароль из AD» (общие настройки) пароль проверяется в Active Directory, но сам механизм формы остается Forms-авторизацией.
Для мобильных приложений доступна двухшаговая авторизация: после ввода пароля приходит SMS/push-код, подтверждение которого завершает аутентификацию.
На форме входа пользователь может выбрать язык интерфейса — по клику на иконку выбора языка раскрывается список доступных языков. Язык можно сменить и позднее, уже после входа в систему.
Восстановление пароля¶
Если пользователь не помнит логин и/или пароль и в компании используется Forms-авторизация, в окне авторизации он нажимает ссылку «Забыли пароль?» и в открывшемся окне выбирает один из трех способов восстановления.
| Способ | Что вводит пользователь |
|---|---|
| По Email — «Получить код восстановления по Email» | E-mail и код безопасности с картинки (капча) |
| По SMS — «Получить код восстановления по SMS» | Номер телефона и капчу |
| По логину — «Получить код восстановления по логину» | Логин, выбор канала доставки кода (Email или SMS) и капчу |
Если символы капчи неразборчивы, по клику на иконку обновления капчи запрашивается новое изображение. После неверного ввода кода безопасности или капчи появляется таймер, и повторный ввод становится доступен через одну минуту.
После заполнения полей пользователь нажимает кнопку Отправить — в течение нескольких минут код восстановления приходит на указанный адрес или номер (если код не получен, нужно обратиться к администратору). Затем открывается следующее окно восстановления — его также можно открыть сразу по ссылке «У меня есть код восстановления» на начальном окне. Поле E-mail или Телефон заполняется системой автоматически; пользователь вводит полученный код, нажимает Далее и регистрирует новый пароль.
При синхронизации с Active Directory для смены пароля дополнительно требуется ввод текущего пароля. При Windows-авторизации самостоятельная смена пароля невозможна — нужно обращаться к администратору.
Смена пароля при истечении срока¶
При истечении срока действия пароля при входе отображается форма смены пароля. Срок действия истекает в трех случаях:
- Превышена сумма даты установки пароля и срока действия пароля из общих настроек.
- При создании пользователя активирован флаг «Сменить пароль при входе».
- Пользователь не входил в систему более 30 дней.
Под полем подтверждения пароля показывается надпись «Пароль не совпадает» (красным), если значения различаются; при совпадении становится активна кнопка Сохранить. После сохранения нового пароля система автоматически выполняет повторную авторизацию с обновленными учетными данными.

Active Directory¶
Аутентификация через доменную инфраструктуру Microsoft. Требования: адрес домена, системная учётная запись, сервер приложений в домене (или DNS-зона на адаптере).
Параметры сервиса: домен, признак корня леса, логин/пароль доступа к AD (опционально, если пользователь приложения имеет нужные права).
Для лесов AD с одноимёнными учётными записями администратор может переключить режим работы с каталогом — подробности в admin.md § «Active Directory».
OpenLDAP¶
Аутентификация через LDAP-каталог (не AD). Параметры: адрес сервера, DN-путь, DN-привязки, пароль.
SSL-подключение настраивается администратором — см. admin.md § «OpenLDAP».
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).
Способы сопоставления пользователя с учётной записью 1Формы, которые может выбрать администратор: - по справочнику (категории); - по произвольному атрибуту профиля; - по учётной записи внешнего сервиса; - по никнейму; - по SID.
Полная настройка сервиса OAuth/OIDC, регистрация провайдера и параметры маппинга — в admin.md § «OAuth / OIDC».
RADIUS¶
Аутентификация через RADIUS-сервер. Минимальная конфигурация: IP-адрес, порт, shared secret.
Windows-аутентификация (Kerberos/NTLM)¶
Поддерживается прозрачная аутентификация через Windows. При настроенной синхронизации с Active Directory учетные данные для входа в Windows автоматически применяются и для входа в 1Форму — пользователю не нужно запоминать дополнительный логин и пароль. Вход через Active Directory возможен также по сертификату SSL.
Для первого входа пользователь после загрузки рабочего стола Windows выбирает ярлык приложения (если он создан) или вводит адрес приложения в браузере. Если в компании требуется согласие на обработку персональных данных, при первом входе показывается экран с текстом соглашения — пользователь включает параметр «Предоставляю согласие...» и нажимает кнопку ОК.
В общих настройках приложения существует параметр «Страница редиректа несуществующих пользователей» — применяется только для Windows-аутентификации.
Многофакторная аутентификация (MFA)¶
Второй фактор настраивается на уровне провайдера аутентификации. Поддерживаемые методы:
SMS¶
Специальное право группы «Подтверждение пароля по SMS (при входе)». На мобильный номер из профиля отправляется 5-значный код. Требуется настроенный SMS-провайдер. Также доступно право «Подтверждение пароля по SMS (при смене)» — для подтверждения смены пароля.
Email¶
Специальное право группы «Двухфакторная аутентификация по Email». На почтовый адрес из профиля отправляется цифровой код. Требуется настроенный SMTP и почтовый ящик для системных писем.
Multifactor (сервис)¶
Интеграция с внешней системой MULTIFACTOR (с версии 2.256). Процесс: пользователь вводит логин/пароль, при успехе система запрашивает MULTIFACTOR, пользователя перенаправляют на страницу второго фактора (мобильное приложение, push, голосовой звонок и т.п.), после подтверждения возвращается на 1Форму и попадает в систему.
Полная настройка (создание сервиса, регистрация в кабинете MULTIFACTOR, конфигурация сертификата) — в admin.md § «Multifactor».
Telegram¶
Специальное право группы «Двухфакторная аутентификация через Telegram». Требуется настроенный Telegram-бот. Процесс: после ввода логина/пароля пользователя перенаправляют в Telegram для подтверждения; после подтверждения он возвращается в 1Форму уже залогиненным.
Настройка: администратор создаёт бота в Telegram (через стандартный @BotFather), регистрирует его реквизиты в сервисе аутентификации 1Формы и выдаёт спецправо группе. Подробности — в admin.md.
Политики паролей¶
Пароли для веб-входа (режим администрирования и сброс)¶
Настройки в разделе «Настройки требований к паролям» общих настроек:
| Параметр | Описание |
|---|---|
| Срок действия пароля (дни) | При истечении — принудительное перенаправление на форму смены (только Forms-авторизация) |
| Минимальная / Максимальная длина | Ограничения длины |
| Спец. символ обязателен | Минимум один символ, не являющийся буквой/цифрой |
| Заглавная буква обязательна | Минимум одна прописная буква |
| Запрет совпадения с предыдущим | Блокировка повторного использования паролей |
| Запрет совпадения с логином | По умолчанию разрешено, можно запретить |
| Длина истории паролей | Количество запоминаемых предыдущих паролей |
| Проверка на дату рождения | Запрет паролей, содержащих дату рождения |
| Минимальная длина последовательности | Обнаружение клавиатурных (qwerty, йцукен) и алфавитных последовательностей |
| Минимальная длина повторяющегося паттерна | Обнаружение повторений типа «qweqwe» |
Срок действия кода для восстановления пароля настраивается отдельно (в днях).
Пароли для самостоятельной регистрации¶
При самостоятельной регистрации действует отдельный набор требований к паролю — он имеет приоритет над общими настройками. Администратор может задать дополнительно: допустимые языки символов, минимум цифр, запрет пробелов, минимум спецсимволов, запрет совпадения с логином/датой рождения, минимальное отличие нового пароля от предыдущих, длину истории паролей.
Полный перечень настраиваемых полей и пример конфигурации — в admin.md § «Самостоятельная регистрация».
Мобильные политики паролей¶
Дополнительный пароль для входа в мобильное приложение, задается для групп:
- Пароль не обязателен
- 4 цифры
- 6 цифр
- Буквенно-цифровой (с регулярным выражением)
При пересечении групп с разными политиками действует наиболее строгая.
Специальное право «Запрещено пользоваться восстановлением пароля» блокирует самостоятельное восстановление пароля для группы.
Защита от подбора и блокировки¶
Общие настройки приложения содержат три параметра защиты:
| Параметр | Действие |
|---|---|
| Максимальное число попыток логина до блокировки | Полная блокировка учетной записи (разблокировка — через администратора) |
| Максимальное число попыток логина пользователя до капчи | Капча после N неудачных попыток для конкретного пользователя |
| Максимальное число попыток логина с IP до капчи | Капча/блокировка IP после N неудачных попыток с одного адреса |
При работе через балансировщик нагрузки администратор должен настроить проброс реальных IP клиентов с прокси/балансировщика — иначе счётчик попыток «с одного IP» увидит только адрес самого балансировщика и заблокирует всех пользователей сразу. Настройка — в admin.md § «Защита от брутфорса».
Геолокация при входе: по умолчанию запрашивается при каждом первом входе. Настройка «Запрашивать геолокацию только после неудачного логина» ограничивает запрос только случаями неудачных попыток.
Самостоятельная регистрация¶
Самостоятельная регистрация пользователей включается администратором: задаётся набор полей формы и допустимые способы (по телефону / по email / по нику).
Правила автозаполнения: - одно из полей «Телефон», «Email» или «Ник» — обязательно; - при заполнении ника обязателен и пароль; - если ник не указан — система автозаполняет его из телефона или email; - если не указано отображаемое имя — оно собирается из «Имя Фамилия» или ника; - при регистрации по телефону или почте поле-источник автоматически заполняется и скрывается.
Администратор может настроить регистрационную ссылку с предзаполненными значениями — пользователь переходит по ней и попадает на форму с уже заполненными полями. Полная настройка — в admin.md § «Самостоятельная регистрация».
Процесс регистрации¶
Регистрация проходит по шагам:
- На форме авторизации — кнопка «Регистрация».
- Выбор способа верификации: по номеру телефона или по email.
- Валидация ввода:
- Email — проверка стандартного формата (
@, доменная часть). При ошибке: «Введите Email». - Телефон — маска
+7 XXX XXX XX XX. При ошибке: «Введите телефон». - Кнопка
Далее→ ввод полученного кода (SMS или email). - Дальше:
- Если пользователь уже был зарегистрирован — перенаправление на стартовую страницу.
- Если пользователь новый — форма регистрации с обязательными полями (набор настраивается администратором).
Требования к паролю при регистрации¶
Требования отображаются при фокусе на поле пароля: серым до ввода, красным при невыполнении, зелёным при выполнении.
Подтверждение пароля имеет онлайн-индикацию: «Пароль не совпадает» (красным) / «Пароль совпадает» (зелёным). Редактирование любого из двух полей запускает повторную проверку.
Кнопка «Регистрация» на финальном шаге активна только когда все обязательные поля заполнены корректно.
Расширенная политика безопасности паролей¶
Администратор может включить дополнительные правила проверки сложности:
- Запрет простых последовательностей (идущие подряд буквы/цифры).
- Запрет повторения одинаковых фрагментов.
- Запрет связи с персональными данными (логин, дата рождения).
- Минимальное отличие от ранее использованных паролей.
SSO (Single Sign-On)¶
SSO позволяет один раз войти во внешнюю систему (Active Directory, ADFS, KeyCloak) и автоматически попадать в 1Форму без повторного ввода логина и пароля. Поддерживаемые протоколы — SAML и OAuth/OpenID Connect.
Пользовательский сценарий простой: на форме входа отображается кнопка с названием провайдера, по клику пользователь перенаправляется во внешнюю систему, проходит там аутентификацию, и возвращается в 1Форму уже залогиненным. При нажатии «Выйти» система не только закрывает локальную сессию, но и сообщает внешнему провайдеру о выходе — чтобы при следующем входе провайдер заново запросил пароль.
Режим перевоплощения¶
Администраторы по умолчанию имеют доступ к перевоплощению — работе в системе от имени другого пользователя. Управление:
- Спецправо «Запретить перевоплощение» — блокирует перевоплощение для группы. Запрещено назначать группе «Администраторы». Администратор с этим правом не может деактивировать его и редактировать состав своей группы.
- Право не переходит заместителю в период замещения.
- Удаление из группы с этим правом через смарт-действие «Удалить пользователя из групп» запрещено.
Персональные токены доступа (PAT)¶
PAT — долгоживущие интеграционные токены для безопасного доступа к API без логина/пароля. Предназначены для автоматизации и внешних интеграций.
Кто может создавать токены¶
Право на создание токенов зависит от роли пользователя:
- Группе можно выдать спецправо «Генерация PAT» — её участники смогут создавать токены на своё имя.
- Администраторы получают эту возможность по умолчанию и могут выдавать PAT любому пользователю.
- Обычные пользователи без спецправа могут просматривать и отзывать свои токены, но не генерировать новые.
Генерация и хранение¶
Токен показывается единожды и в системе не хранится в открытом виде:
- При генерации полная строка токена показывается пользователю один раз — в системе сохраняется только защищённая контрольная сумма, восстановить токен невозможно.
- Пользователь обязан сохранить строку токена самостоятельно; повторно получить её нельзя.
Использование¶
Как применяется выданный токен:
- Токен передаётся в HTTP-заголовке
1F-Patпри вызове API. Технические детали транспорта (в т.ч. для realtime-подключений) — вadmin.md§ «Аутентификация API-запросов». - Пользователь, аутентифицированный через PAT, работает с теми же правами, лицензиями и ограничениями, что и при входе по логину/паролю.
- Рекомендация: выдавать PAT на специального сервисного пользователя в отдельной группе с ограниченными правами.
Ограничения¶
Администратор может задать максимальное число активных токенов на пользователя и максимальный срок жизни токена. По умолчанию — 10 токенов и 365 дней. Подробности — в admin.md § «Personal Access Tokens».
UI управления токенами¶
Страница «Токены доступа» доступна в персональном меню пользователя (между пунктами «Канбан» и «Диск»). Отображается администраторам и пользователям со спецправом «Генерация PAT».
Интерфейс страницы:
- Заголовок «Токены доступа» с фильтром по статусу (по умолчанию — «Активные»).
- Кнопка «+ Создать токен» в правом верхнем углу.
- Таблица столбцов: Название, Токен (маскированный, виден префикс +
****), Статус (Активен/Отозван/Истёк), Активен до, Дата создания, Отозвать (×). - Пустая таблица показывает «Нет данных».
Создание токена:
- Кнопка
+ Создать токен→ модальное окно «Создание токена». - Поля: Название (произвольное), Срок действия (по умолчанию — настроенный администратором максимум).
- Кнопка
Создать(илиОтмена). - Открывается диалог «Токен создан»: предупреждение на жёлтом фоне (токен виден один раз), скрытое значение токена (раскрывается иконкой глаза), кнопка копирования.
- После закрытия диалога новая запись появляется в таблице.
Каждый пользователь, включая администратора, может выпустить токен только для своей учётной записи; выдать токен от имени другого через интерфейс нельзя.
Отзыв токена: кнопка × в колонке «Отозвать» — токен перестаёт работать сразу.
Текущие ограничения¶
У текущей реализации токенов есть несколько ограничений:
- Области действия (scopes) не реализованы — все токены работают с полным набором прав пользователя. Планируется к доработке по бизнес-потребностям.
- Логирование входов по PAT — отдельной записи о входе по PAT в журнале нет; фиксируются только дата и IP последнего использования у самого токена.
- Очистка просроченных или отозванных токенов не автоматизирована — записи остаются в системе как история.
Согласие на обработку персональных данных¶
При включённой настройке «Требовать подтверждение согласия на обработку перс. данных» (общие настройки) система при аутентификации проверяет, давал ли пользователь согласие. Если нет — отображается текст соглашения, и вход возможен только после подтверждения. Согласие хранится в карточке пользователя; администратор может потребовать его повторного подтверждения (например, при изменении текста).
Безопасность транспорта¶
Соединение с системой защищено на транспортном уровне:
- Принудительный HTTPS — все обращения по незащищённому HTTP автоматически перенаправляются на HTTPS.
- HSTS — браузеру предписывается всегда обращаться к сайту только по HTTPS, даже если пользователь набрал адрес без протокола. ⚠️ Настройка необратимая: после включения отключить её невозможно до истечения срока, заданного в политике.
Кастомизация страницы авторизации¶
Внешний вид страницы входа можно оформить под компанию:
| Элемент | Настройка |
|---|---|
| Логотип | Загрузка файла (239x57 px, предпочтительно PNG) |
| Фоновое изображение | Путь к файлу (2000x3000 px, предпочтительно SVG) |
| Текст под логотипом | «Текст на странице логина» |
Связи с другими доменами¶
Аутентификация связана с несколькими смежными доменами:
| Домен | Связь |
|---|---|
| Пользователи и группы | Провайдеры привязываются к группам; спецправа управляют MFA и восстановлением пароля; мобильные политики назначаются группам |
| Синхронизация (AD/1C) | Синхронизация учётных записей из AD и 1С; SAML-автосоздание профилей из атрибутов |
| Уведомления | SMS-провайдеры для MFA; email для кодов и восстановления пароля |
| Порталы | Стартовая страница после входа может быть порталом |
| Календарь / Exchange | Синхронизация с Exchange использует доменную авторизацию и перевоплощение |
| Чаты / Telegram | Telegram-бот для двухфакторной аутентификации |
| Смарт-логика | Глобальное смарт-событие «После создания пользователя» при регистрации |
| Журналы | Журнал входов, белый список IP-адресов, журнал ошибок аутентификации |