Доступ и авторизация¶

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

Вход и авторизация¶

Раздел описывает первичные сценарии входа в мобильное приложение 1Форма и связанные с ними серверные настройки.

Первичные способы входа¶

Доступные сценарии входа зависят не только от платформы, но и от серверной auth-конфигурации.

Сценарий	Что происходит
Логин и пароль	Пользователь вводит логин и пароль учётной записи 1Форма. Сценарий доступен, когда серверная auth-конфигурация разрешает login-pass.
SMS-код	Пользователь вводит номер телефона, получает одноразовый код и подтверждает вход.
Внешний провайдер (OAuth / SAML)	Вход выполняется через настроенного SSO-провайдера.
QR-код	На этапе добавления учётной записи клиент может получить из QR адрес сервера и часть учётных данных(логин и/или номер телефона), после чего продолжает выбранный auth-flow.

PIN-код, Face ID, Touch ID и Android-биометрия не являются первичным способом входа на "чистом" клиенте. Это сценарии повторного входа и разблокировки после первой успешной авторизации.

Как выбирается сценарий входа¶

Поведение клиента определяется серверной auth-конфигурацией, а не только платформой.

Мобильыне клиенты не показывают отдельный универсальный список вариантов. После проверки адреса сервера клиент маршрутизирует пользователя по authTemplate.type: телефонный шаблон ведёт в SMS-сценарий, а login / email / пустой шаблон ведёт на экран логина и пароля.
Если у клиента основной сценарий — SMS, но сервер также разрешает логин и пароль, в SMS-экране появляется кнопка «У меня есть логин и пароль». Этот fallback зависит от server-side набора auth templates (showLoginAuth / наличие login-template).
SAML/OAuth на iOS не ограничены Android-платформой: при выборе соответствующего провайдера клиент обрабатывает их в общем login-flow.

Регистрация новых пользователей¶

Самостоятельная регистрация показывается не всегда. Её доступность определяется серверной auth-конфигурацией и ответом сервера в конкретном сценарии авторизации.

Для телефонного сценария экран регистрации открывается только после серверного ответа RegistrationAllowed.
Блок согласия на экране регистрации зависит от серверной ссылки registerPrivacyLink / политики конфиденциальности.
Минимально подтверждённые обязательные поля — имя и фамилия. Дополнительные поля и точный состав формы зависят от клиента и конфигурации сервера.
Если сервер не разрешает регистрацию, переход в этот сценарий в клиенте не появляются.

Повторный вход: PIN-код и биометрия¶

После первой успешной авторизации клиент может перевести пользователя на сценарий повторного входа:

PIN-код приложения — задаётся после первичного входа и используется при следующем запуске или разблокировке приложения.
Биометрия — работает как альтернатива PIN-коду, если она настроена на устройстве.
На iOS возможность выбрать режим "никогда не блокировать" зависит от серверной политики пароля и признака canSelectNeverLock.

Политика паролей¶

Требования к паролю (минимальная длина, обязательность специальных символов, срок действия и т.д.) задаются на стороне сервера в настройках безопасности. Мобильное приложение получает эти требования автоматически и показывает пользователям соответствующие подсказки при смене пароля.

Обновление токена¶

После успешной авторизации клиент хранит access/refresh-token и при истечении access-token пытается выполнить автоматическое обновление сессии. Если refresh-сценарий завершился ошибкой или сервер требует повторной аутентификации, пользователю предлагается войти заново.

Роли и права доступа¶

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

Группа «Administrators»¶

Пользователь, входящий в группу Administrators на сервере 1Форма, получает расширенные права в мобильном приложении.

Что доступно администратору дополнительно:

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

Принадлежность к группе Administrators проверяется автоматически при входе в систему — отдельно включать это в МП не нужно.

Режим «Гостей»¶

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

Что ограничено для гостей:

Нельзя добавлять подписчиков к задачам.
Скрыты определённые кнопки действий (зависит от конкретного экрана).
В некоторых местах интерфейса ограничены действия с контентом.

Перевоплощение под другого пользователя¶

В карточке пользователя (только для администратора) при лонгтапе на аватар/из меню три точки может отображаться пункт «Impersonate» — возможность временно войти в систему от имени этого пользователя. Это позволяет администратору воспроизвести проблему, с которой столкнулся конкретный пользователь, видя интерфейс его глазами.

Функция доступна только если: - текущий пользователь не находится уже в режиме «перевоплощения», - текущий пользователь — администратор, - для целевого пользователя на сервере включён флаг canImpersonate.

После входа в режим «перевоплощения» в боковом меню/в верхней панели появляется UI-элемент «Отменить перевоплощение» — она возвращает пользователя к его собственной учётной записи.

Итоговая таблица прав¶

Возможность	Обычный пользователь	Гость	Администратор
Просмотр задач	✅	✅ (ограниченно)	✅
Создание задач	✅	✅ (ограниченно)	✅
Удаление чужих задач	❌	❌	✅
Изменение чужих задач	❌	❌	✅
Добавление подписчиков	✅	❌	✅
Изменение аватара другого пользователя	❌	❌	✅
Вход от имени другого пользователя	❌	❌	✅ (если разрешено)