Как описать авторизацию через Госуслуги в ТЗ

Коротко: Чтобы правильно прописать интеграцию с ЕСИА в ТЗ, необходимо зафиксировать использование подтвержденной учетной записи, предусмотреть сценарий авторизации через мобильное приложение Госуслуг (Цифровой профиль) и учесть обязательное использование УКЭП для доступа к технологическому порталу. ТЗ должно исключать создание локальных паролей и фокусироваться на бесшовном переходе пользователя между системами через единую идентификацию.

Кстати, в AmSales мы делаем разработку мобильных приложений и разработку личных кабинетов под ключ. Если нужна помощь - напишите нам.

Роль ЕСИА в современной архитектуре систем

Сегодня разработка любого сервиса, который взаимодействует с государственными данными или требует высокого уровня доверия к личности пользователя, начинается не с выбора базы данных, а с проектирования модели идентификации. Единая система идентификации, аутентификации и авторизации (ЕСИА) перестала быть просто «входом через Госуслуги». Теперь это фундамент, на котором строится межведомственное взаимодействие и доступ к государственным цифровым ресурсам.

Для бизнеса и разработчиков важно понимать, что ЕСИА - это не альтернатива вашей базе пользователей, а надстройка, которая берет на себя самые сложные и рискованные процессы. Вам не нужно хранить сканы паспортов или проверять подлинность СНИЛС. Система сама передает вам уже верифицированные атрибуты. Это снимает с компании колоссальную нагрузку по соблюдению требований безопасности и защите персональных данных.

В 2026 году архитектурный подход изменился окончательно. Если раньше интеграция с ЕСИА в ТЗ часто описывалась как опциональный модуль для «удобства», то сейчас это стандарт де-факто для систем, работающих в рамках инфраструктуры «ГосТех» или взаимодействующих с ведомственными сервисами. Например, доступ к функционалу ФИС ГНА теперь осуществляется исключительно через ЕСИА. Пытаться построить параллельную систему авторизации в таких случаях - значит обрекать продукт на технологическое отставание и юридические риски.

При проектировании важно разделять типы доступа. Существует пользовательский сегмент (обычные граждане через мобильные приложения) и технологический сегмент (автоматизированные системы и разработчики). Требования к ним различаются. Если для гражданина важен комфорт и скорость, то для доступа к технологическому порталу ЕСИА с 1 августа 2026 года вводятся жесткие условия: обязательное использование УКЭП и подтверждение входа по СМС. Это критическая деталь, которую нельзя упускать при составлении требований к ТЗ на авторизацию.

Модели интеграции: классика против современных стандартов

Раньше разработчики часто предлагали гибридную модель: пользователь регистрируется у нас, а потом «привязывает» Госуслуги. Сегодня такой подход считается устаревшим и избыточным. Современная модель подразумевает, что ЕСИА является первичным источником истины. Пользователь авторизуется в вашей системе, используя свои учетные данные Госуслуг, и ваша система получает его профиль без необходимости создавать промежуточные связки.

Такой подход исключает проблему «забытых паролей» в вашей системе и минимизирует количество регистрационных форм. Чем меньше полей заполняет пользователь, тем выше конверсия. Интеграция с ЕСИА в ТЗ должна описывать именно этот процесс: запрос атрибутов, обработку ответа от провайдера и создание (или обновление) профиля в вашей базе на основе полученных данных.

Сценарий подтверждения согласия через Цифровой профиль

Одним из самых важных и технически сложных этапов является получение согласия на обработку данных. Просто «поставить галочку» в интерфейсе уже недостаточно для серьезных сценариев. Современный стандарт взаимодействия предполагает использование механики «Цифрового профиля». Это позволяет пользователю не вводить данные вручную, а подтвердить их передачу одной кнопкой в привычном окружении.

Согласно актуальным инструкциям от сентября 2026 года, сценарий выглядит следующим образом. Пользователь инициирует запрос в вашем приложении (например, в банковском или страховом). Система перенаправляет его в мобильное приложение «Госуслуги». Там пользователь получает пуш-уведомление или видит запрос в личном кабинете. После подтверждения согласия происходит автоматический возврат пользователя в ваше приложение. Это может быть реализовано через переход по ссылке, QR-код или уведомление. Ваша задача в ТЗ - четко прописать этот цикл перенаправлений (редиректов) и обработку состояний, когда пользователь прервал процесс на стороне Госуслуг.

Этот процесс значительно повышает доверие. Когда человек видит, что подтверждение происходит в официальном приложении, уровень тревожности падает. Для разработчика это означает необходимость тщательной проработки обработки callback-уведомлений. Вы должны точно знать, в какой момент согласие считается полученным и как система должна реагировать, если сессия в приложении «Госуслуги» была завершена некорректно.

Механики подтверждения: три основных пути

При описании логики в ТЗ стоит предусмотреть несколько вариантов взаимодействия, чтобы интерфейс был устойчив к разным сценариям использования. В зависимости от платформы (Web или Mobile), пути могут отличаться:

1. Переход через пуш-уведомление: самый быстрый путь для мобильных пользователей.
2. Сканирование QR-кода: идеальный вариант, если пользователь работает через десктопную версию вашего сервиса.
3. Личный кабинет на портале: классический вариант, когда пользователь сам заходит в ЕСИА для управления доступами.

Важно понимать, что «Цифровой профиль» - это не просто способ подтвердить личность, это способ передать набор согласованных данных. В ТЗ нужно указать не только факт согласия, но и конкретный перечень атрибутов, которые будут запрошены через этот механизм. Не запрашивайте лишнего: если вам нужен только СНИЛС, не требуйте доступа к адресу регистрации. Избыточность запросов снижает конверсию и вызывает подозрение у контролирующих органов.

Особенности авторизации с использованием УКЭП

С августа 2026 года правила игры для профессиональных участников рынка существенно ужесточились. Если раньше авторизация через Госуслуги для разработчиков могла быть связана только с логином и паролем, то теперь для доступа к технологическим шлюзам ЕСИА требуется усиленная квалифицированная электронная подпись (УКЭП). Это фундаментальное изменение, которое должно быть отражено в каждом ТЗ, касающемся интеграции с государственными системами.

УКЭП используется не для того, чтобы «подписать документ» в привычном понимании, а как фактор строгой аутентификации. Это гарантирует, что запрос на получение данных или выполнение транзакции исходит именно от авторизованного представителя организации или конкретного технического специалиста. Без наличия действующего сертификата УКЭП вход на технологический портал ЕСИА теперь технически невозможен. Это не просто рекомендация Минцифры, а реализованное на уровне протоколов требование безопасности.

При описании этого процесса в ТЗ необходимо разделить сценарии для обычных пользователей и для администраторов/разработчиков. Обычный гражданин, заходя в ваш сервис через Госуслуги, не обязан иметь УКЭП. Но если ваш сервис предполагает взаимодействие с государственными реестрами от имени организации, архитектура должна поддерживать проверку подписи на стороне сервера. Вы должны прописать, как система будет проверять валидность сертификата, как обрабатывать его истечение и что делать, если подпись не прошла проверку.

Также не забывайте про второй фактор. С августа 2026 года обязательным стало подтверждение входа через СМС даже при наличии УКЭП для технологического доступа. Это создает многофакторную модель защиты, которая практически исключает возможность несанкционированного доступа при компрометации ключа подписи. В ТЗ это должно выглядеть как последовательная цепочка проверок: наличие сертификата -> валидация цепочки доверия -> проверка СМС-кода.

Требования к данным паспорта и СНИЛС

Авторизация через Госуслуги - это только половина дела. Главная ценность заключается в получении атрибутов пользователя. Чтобы пользователь получил «полный доступ» к функционалу, который требует верификации, его учетная запись в ЕСИА должна быть подтвержденной. Это означает, что в системе Госуслуг уже должны быть корректно заполнены и верифицированы данные паспорта и СНИЛС.

В ТЗ крайне важно прописать логику обработки ситуаций, когда предоставленные через ЕСИА данные не соответствуют вашим внутренним требованиям или когда они отсутствуют. Например, если ваш сервис требует обязательного наличия СНИЛС для расчета налоговых вычетов, а в ответе от ЕСИА этот атрибут пуст или не верифицирован, система должна выдать понятную пользователю инструкцию. Нельзя просто выдать ошибку «403 Forbidden» или «Данные не получены». Пользователь должен понимать: «Ваша учетная запись в Госуслугах не подтверждена. Пожалуйста, завершите процедуру подтверждения в личном кабинете ЕСИА, чтобы продолжить».

Важный нюанс: данные, полученные из ЕСИА, должны проходить автоматическую валидацию на соответствие форматам. СНИЛС имеет строго определенную структуру, паспортные данные - свои правила. Если вы планируете использовать эти данные для автоматического заполнения документов или создания профиля в CRM, в ТЗ нужно зафиксировать правила маппинга (сопоставления) полей. Например, как обрабатывать серии и номера паспорта, если они приходят в разных форматах в зависимости от типа документа.

Типичные ошибки при описании логики входа

Опыт показывает, что большинство проблем с интеграцией возникает не на этапе написания кода, а на этапе проектирования. Ошибки в ТЗ приводят к тому, что разработчики создают систему, которая либо небезопасна, либо абсолютно неудобна для пользователя. Самая распространенная ошибка - попытка воссоздать «свой вход» поверх ЕСИА. Разработчики описывают сценарий как «обычный логин и пароль без дополнительного подтверждения», забывая, что для актуальных сценариев ЕСИА требуется подтвержденная учетная запись и дополнительные факторы проверки.

Вторая критическая ошибка - игнорирование состояний ошибки. В ТЗ часто пишут только «счастливый путь» (happy path): пользователь нажал кнопку, авторизовался, вошел. Но что если у пользователя истек срок действия сертификата? Что если он отклонил запрос на передачу данных в приложении «Госуслуги»? Что если связь с сервером ЕСИА прервалась в момент передачи токена? Если эти сценарии не описаны, система будет «падать» или выдавать непредсказуемые результаты, что моментально убивает доверие пользователя.

Третья ошибка - отсутствие требований к обновлению данных. Данные пользователя могут измениться: он сменил паспорт или фамилию. Если ваша система один раз получила данные и «забыла» о них, вы получите рассинхронизацию. В ТЗ нужно четко указать: должна ли система периодически перепроверять актуальность данных через ЕСИА или она полагается только на первичную авторизацию? Это влияет на архитектуру хранения данных и на частоту запросов к API.

Наконец, многие забывают про безопасность сессий. Авторизация через ЕСИА дает токен, который позволяет работать в вашей системе. В ТЗ необходимо прописать время жизни этого токена, правила его обновления и механизм принудительного разлогина. Использование устаревших подходов к управлению сессиями в связке с современными государственными системами идентификации - это прямой путь к уязвимостям.

Единый вход без повторного ввода пароля

Одним из главных преимуществ использования ЕСИА является концепция Single Sign-On (SSO) - единого входа. Современная модель доступа предполагает, что после первой авторизации в одной системе, использующей ЕСИА, повторный ввод логина и пароля в других интегрированных системах не требуется. Это не просто «фишка» для удобства, это фундаментальный принцип работы цифровой среды в 2026 году.

При проектировании интерфейсов важно учитывать этот эффект. Если пользователь уже прошел аутентификацию в государственном приложении или в другом сервисе вашей экосистемы, ваша система должна уметь бесшовно подхватить его сессию. Это требует правильной настройки протоколов обмена (например, OpenID Connect или SAML), которые должны быть детально описаны в технической части ТЗ. Разработчик должен понимать, как именно ваша система будет узнавать «уже авторизованного» пользователя.

Однако здесь кроется и сложность. Бесшовность не должна идти в ущерб безопасности. Если пользователь переходит из высокорискового сервиса (например, банковского) в менее защищенный (информационный портал), стоит ли позволять ему вход без повторной проверки? В ТЗ нужно определить уровни доверия (LoA - Levels of Assurance) для разных разделов вашего продукта. Для чтения новостей достаточно базовой идентификации, а для совершения финансовых операций может потребоваться повторное подтверждение через ЕСИА или использование УКЭП.

Правильно реализованный SSO повышает лояльность. Пользователь чувствует, что он находится внутри единого, понятного и технологичного пространства. Это снижает когнитивную нагрузку: ему не нужно держать в голове десяток паролей, он просто пользуется сервисами. Ваша задача как автора ТЗ - сделать так, чтобы эта магия работала стабильно и предсказуемо.

Как составить техническое задание для разработчика

Подводя итог, давайте соберем все разрозненные требования в единый алгоритм действий. Хорошее ТЗ на интеграцию с ЕСИА - это не просто список функций, это описание жизненного цикла пользователя в системе. Оно должно быть структурированным, логичным и учитывать как технические протоколы, так и пользовательский опыт.

При составлении документа рекомендую придерживаться следующего порядка:

1. Определите цели интеграции: вам нужна только идентификация или вы планируете запрашивать глубокие атрибуты через Цифровой профиль?
2. Опишите архитектурную модель: будет ли это прямая интеграция или использование промежуточного шлюза.
3. Детально пропишите сценарии (Use Cases): как происходит вход, как происходит подтверждение согласия, как обрабатываются ошибки.
4. Укажите требования к безопасности: использование УКЭП для администраторов, требования к двухфакторной аутентификации, управление сессиями.
5. Сформируйте таблицу маппинга данных: какие поля из ЕСИА приходят и в какие поля вашей базы они записываются.
6. Определите требования к UI/UX: как визуально отображается процесс перехода в Госуслуги и как обрабатываются состояния ожидания.

Помните, что разработчик - это не человек, который должен догадаться, как работает Госуслуги. Это специалист, который будет реализовывать ваши инструкции. Чем меньше в ТЗ будет фраз вроде «сделать удобно» и чем больше будет фраз «при получении ошибки 401 отправить редирект на страницу X с параметром Y», тем качественнее будет результат. Интеграция с ЕСИА - это сложный, высокотехнологичный процесс, который не терпит приблизительности.

Что запомнить:

• ЕСИА - это не просто логин, это единая система идентификации и источник верифицированных данных.
• С 1 августа 2026 года для технологического доступа обязательна УКЭП и СМС-подтверждение.
• Используйте сценарий «Цифрового профиля» для бесшовного получения согласия через мобильное приложение.
• Никогда не описывайте вход как «простой логин/пароль» - это не соответствует актуальным требованиям безопасности.
• ТЗ должно содержать четкие инструкции по обработке ошибок и обновлению данных пользователя.