Модуль авторизации ЕСИА

Авторизация (получение авторизационного кода)

Параметры:

Примеры:

Для инициации процесса идентификации и аутентификации пользователей через ЕСИА необходимо сформировать авторизационный запрос и передать его на соответствующий URL шлюза. Для пользователя с вышеуказанными параметрами ссылка будет иметь следующий вид.

Выписка с данными в исходном виде:

Получение данных о документах в исходном виде происходит так же путем указания scope.Сервис доступен для типов документов VEHICLE_INFO (Выписка
о транспортном средстве по владельцу), ILS_PFR (Cведения о состоянии индивидуального
страхового счета застрахованного лица)

, PAYOUT_INCOME (Сведения о доходах
физического лица и о выплатах страховых взносов, произведенных в пользу физического
лица). Но в случае запроса данных ответ может поступить не сразу, а в течении некоторого времени.В случае, если сведение запрошено в ведомстве и ответ еще не поступил, возвращается
идентификатор этого запроса и идентификатор пользователя (oid).

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

Пример ответа в случае запроса openid и fullname из защищённого хранилища ЕСИА:

{"sub":"3","info":{"uid":"1000486446","stateFacts":["EntityRoot"],"firstName":"Тимофей","lastName":"Сазонов","middleName":"Трофимович","trusted":true,"updatedOn":1633359785,"status":"REGISTERED","verifying":true,"rIdDoc":160710,"containsUpCfmCode":false,"eTag":"A543E45F09EDC6AEE19530A674E636B54F9A29CC"}}

Выход из системы есиа

Параметры:

Для получения данных отправляется GET запрос

Для инициации процесса выхода из системы ЕСИА необходимо сформировать авторизационный запрос и передать его на соответствующий URL шлюза. Для пользователя с вышеуказанными параметрами ссылка будет иметь следующий вид:

ВАЖНО! Путь возврата пользователя обязательно должен быть указан в соответствующей КИС

Доступ к сервисам шлюза

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

Для доступа к сервисам шлюза потребуются следующие реквизиты:

Значение идентификатора и секрета для КИС берутся из её параметров в административной панели шлюза.

ЕСИА Шлюз не занимается валидацией скоупов, переданных клиентской системой. Скоупы просто передаются в ЕСИА. Поэтому .well-known/openid-configuration содержит пустой массив в scopes_supported.

Зачем нам есиа?

Согласно Федеральному закону № 225-ФЗ от 28.06.2021 «О внесении изменений в часть первую Гражданского кодекса Российской Федерации», многие организаций в РФ получили право проводить официальные собрания и голосования по корпоративным вопросам дистанционно.

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

Чтобы проводить мероприятия принятия решения дистанционно в соответствии с новым федеральным законом, необходимо предоставить возможность достоверного установления личности участников. В России это возможно через проверку доступа к верифицированному аккаунту на Госуслугах.

Модуль авторизации есиа

Модуль представляет собой набор файлов c исходным кодом. Имеются модификации на языках программирования PHP, C# (.Net), Java, Ruby, Python, а также готовые компоненты для CMS Bitrix (1С-Битрикс «Управление сайтом» и «Корпоративный портал»), WordPress, Drupal и Joomla и Moodle.

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

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

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

Модуль поддерживает биометрическую идентификацию и соответствует требованиями Методических рекомендаций единой биометрической системы (ЕБС) и Методическим рекомендациям по использованию Единой системы идентификации и аутентификации.

Общие положения

Взаимодействие клиентской системы с сервисами шлюза, обеспечивающими идентификацию пользователей через ЕСИА, происходит через стандартный протокол OAuth 2.0/OpenID Connect. Авторизация в ЕСИА происходит, в данном случае, как обычная OAuth авторизация.

Для работы с данным протоколом имеются готовые открытые реализации под большинство популярных программных платформ.

Чтобы начать работу с ЕСИА Шлюзом необходимо интегрировать в целевую информационную систему одно из готовых средств, реализующих работу с протоколом OAuth 2.0.

Спецификация OpenID Connect

Получение данных пользователя

Параметры:

access_token — токен доступа.

Для получения данных отправляется GET запрос

на url при этом в параметре запроса access_token передается токен доступа.

Пример запроса на получение данных:

На основе полученного токена доступа шлюз предоставляет клиентским системам доступ к областям данных из защищённого хранилища ЕСИА.

ВАЖНО! В соответствии с законодательством перечень скоупов доступных для клиентских систем шлюза может быть ограничен. Поэтому, прежде чем указывать перечень скоупов в запросе к шлюзу, необходимо сверить этот перечень с перечнем скоупов указанным в заявке на подключение к тестовой/промышленной ЕСИА.

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

Получение документов из цифрового профиля:

Запрос документов происходит так же, как и запрос других данных — путем указания нужного scope. Но в случае запроса документа ответ может поступить не сразу, а в течении некоторого времени.В случае, если сведение запрошено в ведомстве и ответ еще не поступил, возвращается
идентификатор этого запроса и идентификатор пользователя (oid).

С помощью идентификатора
запроса осуществляется процесс обработки персональных данных. Для возможности получения
сведения о документах необходимо обновить запрос. Для типа документа
INCOME_REFERENCE (Справка о доходах и суммах налога физического лица (форма 2-НДФЛ))
дополнительно указывается параметр year – год, за который успешно получена справка 2-НДФЛ
в ведомстве.

В случае, если у пользователя нет информации по следющим сведениям: FID_BRTH_CERT,
OLD_BRTH_CERT, RF_BRTH_CERT, MARRIED_CERT, DIVORCE_CERT,
NAME_CHANGE_CERT и FATHERHOOD_CERT, то в ответе на запрос вернется ошибка 404.
Перечень параметров, которые возвращаются по каждому типу документа (doc_type),
приведены в разделе 7.2 методических рекомендаций.

Получение токена доступа (обмен авторизационного кода на токен доступа)

Параметры:

На предыдущем шаге после успешной авторизации в ЕСИА был получен авторизационный код, который следует обменять на токен доступа (access_token) для его последующего использования при получении пользовательских данных. Один код можно обменять только на один токен. Для этого отправляем POST запрос на url

со следующими параметрами запроса:

Пример запроса получения access_token:

Будет получен следующий ответ.

В поле access_token пользовательских данных.

Создание ссылки для редиректа на страницу есиа

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

async getAuthLink(redirectLink: string) { const params = await this.signParams({ redirect_uri: redirectLink, response_type: 'code', access_type: 'offline', }) const authQuery = new URLSearchParams(params) const authURL = `${this.esiaHost}/aas/oauth2/ac` return `${authURL}?${authQuery}`
}

В redirectLink необходимо указать адрес страницы, на которую ЕСИА перенаправит пользователя после успешной аутентификации. Созданную ссылку возвращаем на фронтенд и перенаправляем на нее пользователя.

Стек и схема интеграции

Для интеграции мы используем:

Формирование подписи

Прежде чем разбирать все по порядку, кое о чем стоит подумать заранее. В отличие от других интеграций, запросы к ЕСИА должны сопровождаться подписью ГОСТ Р 34.10/11-2022, а не просто API key. Создать такую подпись можно с помощью утилиты КриптоПро CSP.

Для нас основная задача здесь — правильно обернуть эту утилиту в Docker, чтобы с ней можно было работать как с отдельным сервисом в рамках нашей инфраструктуры. Получившийся сервис мы выложили в открытый доступ на гитхабе. Инструкция по запуску есть в README.md.

В процесс сборки Docker образа сервиса с утилитой КриптоПро мы встроили:

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

private async signParams(params: Record<string, string>) { const time = moment().format('YYYY.MM.DD HH:mm:ss ZZ') const state = uuid() const clientId = this.clientId const scope = this.scope const { data: { result: clientSecret } } = await axios.post<{ result: string }>( `${this.cryptoProServiceAddress}/cryptopro/sign`, { text: [scope, time, clientId, state].join('') }, ) return { ...params, timestamp: time, client_id: clientId, scope, state, client_secret: clientSecret.replace(/n/g, ''), }
}

С созданием подписей разобрались, теперь последовательно разберем, как реализовать схему выше.

Похожее: Аутентификация (Laravel 5.0) — Laravel Framework Russian Community