Ошибка esia 005048

Получение операторского маркера доступа для управления пользователями

Примечание

Данный сценарий не требует интерактивного взаимодействия Пользователя с Веб-интерфейсом ЦИ DSS.

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

Перед началом интеграции Администратору DSS необходимо:

• Выпустить и зарегистрировать на DSS cертификат аутентификации Оператора DSS
• Зарегистрировать OAuth-клиента

Для получения маркера доступа необходимо выполнить следующие шаги:

Инициация аутентификации

Данный шаг заключается в отправке GET-запроса на аутентификацию на конечную точку /authorize/certificate. Примера запроса представлен ниже.

Пример запроса

• client_id — идентификатор клиента OAuth, зарегистрированный на ЦИ DSS. Для регистрации клиента и его последующей конфигурации можно воспользоваться командлетами Windows PowerShell Add-DssClient и Set-DssClient соответственно.

Примечание

При регистрации клиента параметр AllowedFlow должен включать в себя разрешения AuthorizationCode и ResourceOwner .

• response_type — в данном сценарии имеет значение code .
• scope — области использования маркера. Должен содержать значение dss.
• redirect_uri — зарегистрированный на Центре Идентификации адрес возврата (по этому адресу будет возвращён запрошенный код авторизации).

Примечание

Значение параметра должно соответствовать значению адреса возврата, заданного при регистрации клиента на ЦИ.

Для случаев, в которых не планируется использование выделенного HTTP-сервиса для обработки URI перенаправления, рекомендуется использовать зарезервированный URI urn:ietf:wg:oauth:2.0:oob:auto .

• resource — идентификатор ресурса, для доступа к которому выпускается токен.

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

Параметр client_id в теле запроса должен был заменен на заголовок Auhtorization HTTP-запроса, имеющий значение Basic Base64(client_id:client_secret) .

Также необходимо указать операторский сертификат в качестве клиентского SSL/TLS сертификата, по нему будет осуществляться аутентификация оператора на ЦИ.

Получение кода авторизации

В случае успешной аутентификации

• ответ сервера будет иметь статус HTTP 302
• В заголовке Location будет содержаться код авторизации

В примере используется специальное значение redirect_uri, клиенту необходимо из заголовка Location извлечь значение параметра code. Значение параметра code будет использовано для получения AccessToken на следующем шаге.

Пример ответа

Типовые ошибки

Получение операторского маркера доступа

Для получения маркера доступа используется конечная точка /token. Клиент формирует следующий HTTP-запрос:

• grant_type — в данном сценарии имеет значение authorization_code .
• code — код авторизации, полученный на предыдущем этапе.
• redirect_uri — зарегистрированный на Центре Идентификации адрес возврата (по этому адресу будет возвращён запрошенный код авторизации).

Примечание

Значение параметра должно соответствовать значению адреса возврата, заданного при регистрации клиента на ЦИ.

• client_id — идентификатор клиента OAuth, зарегистрированный на ЦИ DSS.

В случае успешной обработки запроса Центром Идентификации ответ будет содержать:

• access_token — Маркер доступа, выпущенный Центром Идентификации DSS
• token_type — Тип токена
• expires_in — Время жизни токена в секундах

Значение параметра access_token необходимо будет использовать при обращениях к Сервису Подписи.

Примечание

Данный access_token не даёт право Оператору DSS выполнять операции на Сервисе Подписи от имени пользователей. access_token может быть использован для получения Политики Сервиса Подписи.

Получение делегирующего маркера доступа

Для получения AccessToken для делегирования используется конечная точка oauth/token. Подробная информация по протоколу получения AccessToken для делегирования: OAuth 2.0 Token Exchange.

• grant_type — тип разрешения, в данном сценарии равен urn:ietf:params:oauth:grant-type:token-exchange.
• resource – идентификатор Сервиса Подписи.
• actor_token — Маркер доступа, полученный на предыдущем шаге
• actor_token_type – тип маркера доступа, должен иметь значение urn:ietf:params:oauth:token-type:jwt.
• subject_token_type – тип маркера доступа, должен иметь значение urn:ietf:params:oauth:token-type:jwt.
• subject_token – неподписанный JWT-токен, содержащий логин управляемого пользователя.

В декодированном виде subject_token имеет вид:

Пример кодирования JWT-токена можно посмотреть по ссылке.

Первая часть (до точки) называется header, вторая – payload. Для получения закодированного значения необходимо выполнить следующее преобразование:

Примечание

Поле unique_name должно содержать логин пользователя, для которого осуществляется делегация прав.

Поля nbf , exp и iat представляют из себя даты в формате Unix Epoch и задают дату начала действия токена, дату истечения срока действия и дату подписания токена соответственно.

Внимание!

Символ “.” в конце получившегося значения является обязательным.

В заголовке Authorization HTTP-запроса клиент должен передать идентификатор OAuth-клиента и секрет (если используется): Authorization: Basic Base64( : )

Пример запроса

В случае успешной обработки запроса Центром Идентификации ответ будет содержать:

• access_token — делегирующий AccessToken, выпущенный Центром Идентификации DSS
• token_type — Тип токена
• expires_in — Время жизни токена в секундах

Значение параметра access_token необходимо будет использовать при обращениях к Сервису Подписи во время выполнения операции оператором от имени пользователя.

Источник

Приложение В. Сервисы ЕСИА, основанные на протоколе OAUTH2.0 и OPENID CONNECT 1.0

Сервисы ЕСИА, основанные на протоколе OAUTH2.0 и OPENID CONNECT 1.0

В.1 Общие сведения

OAuth 2.0 определяет протокол взаимодействия следующих сторон:

— владелец ресурса (resource owner) — сущность, которая может предоставить доступ к защищаемому ресурсу (например, конечный пользователь);

— система-клиент (client) — приложение, которое запрашивает доступ к защищаемому ресурсу от имени владельца ресурса;

— сервис авторизации (authorization server) — сервис, который выпускает для клиента маркеры доступа с разрешения владельца ресурса;

— поставщик ресурса (resource server) — сервис, на котором размещены защищаемые ресурсы, и который может принимать запросы на доступ к защищаемым ресурсам и отвечать на эти запросы.

Модель контроля доступа, реализуемая сервисом авторизации ЕСИА, основана на использовании маркера доступа (security access token). Этот маркер несет информацию о подмножестве полномочий системы-клиента, о самой системе-клиенте, а также ряд служебных параметров. С точки зрения системы-клиента маркер доступа представляет собой набор символов. Системе-клиенту для получения доступа к защищенным ресурсам (т.е. делать успешные вызовы программного интерфейса), как правило, не требуется расшифровывать маркер доступа, достаточно лишь получать по определенным правилам и корректно использовать. В то же время в ЕСИА предусмотрены и «подписанные» маркеры доступа, которые можно проверить без обращения к ЕСИА.

В ЕСИА используются два способа получения маркера доступа:

1. Система-клиент получает маркер доступа в результате делегированного принятия решения сервисом авторизации на основании согласия владельца ресурса. В этом случае сервис авторизации выдает маркер доступа, если явными # образом получает разрешение со стороны владельца ресурса. Например, система-клиент обратилась к сервису авторизации за маркером, позволяющим получить контактные данные пользователя. В этом случае сервис авторизации запрашивает у пользователя, согласен ли он предоставить данные системе-клиенту, и при позитивном решении выдает маркер доступа.

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

Аутентификация пользователя, реализуемая с помощью модели OAuth 2.0 и распишения OpenID Connect, основана на использовании маркера идентификации (ID token). Этот маркер несет информацию об идентификационных данных пользователя, а также ряд служебных параметров.

В.2 Модель контроля на основе делегированного принятия решения

В.2.1 Общие принципы

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

В общем виде схема взаимодействия выглядит следующим образом:

— система-клиент запрашивает у владельца ресурса разрешение на доступ к соответствующим ресурсам. Обычно этот запрос осуществляется не напрямую к владельцу ресурса, а опосредованно через сервис авторизации (который, в свою очередь, запрашивает разрешение у владельца ресурса), поскольку сам владелец ресурса не может выдать ни маркер доступа, ни авторизационный код;

— система-клиент получает разрешение на доступ (authorization grant) в виде авторизационного кода;

— система-клиент запрашивает маркер доступа, предъявив авторизационный код сервису авторизации;

— сервис авторизации аутентифицирует систему-клиента, проверяет авторизационный код и выдает маркер доступа и маркер обновления;

— система-клиент запрашивает у поставщика защищенный ресурс, предъявляя маркер доступа;

— поставщик ресурса проверяет маркер доступа, если он валиден, то разрешает доступ к защищенному ресурсу;

— система-клиент вновь запрашивает с помощью выданного ранее маркера доступ к защищенному ресурсу;

— поставщик ресурса проверяет маркер, обнаруживает, что срок его действия истек, возвращает сообщение об ошибке;

— система-клиент обращается к сервису авторизации за получением нового маркера доступа, предъявляя маркер обновления;

— сервис авторизации проверяет валидность маркера обновления и возвращает два новых маркера: доступа и обновления.

Схема взаимодействия представлена на рисунке 14.

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

Ключевая особенность этой модели в том, что сам владелец ресурса никогда не получает маркер доступа, его получает сама система-клиент в результате прямой связи с сервисом авторизации (server-side flow).

Рисунок 14 — Общая схема взаимодействия при получении маркера доступа с помощью авторизационного кода

Для оптимизации повторного получения маркера доступа используется механизм маркера обновления (refresh token): в этом случае первоначально в обмен на авторизационный код системе-клиенту выдается не только маркер доступа, но и маркер обновления. Когда маркер доступа перестает действовать, система-клиент обращается к сервису авторизации за получением нового маркера доступа, предъявляя маркер обновления. Сервис авторизации проверяет валидность маркера обновления (что он не был отозван и что срок его действия не истек) и выдает новый маркер доступа и маркер обновления.

Особенности маркера обновления:

— имеет более длительный (или бессрочный) срок действия, чем у маркера доступа;

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

— выдается сервисом авторизации одновременно с маркером доступа;

— может быть отозван владельцем ресурса.

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

В.2.2 Получение авторизационного кода

Чтобы получить авторизационный код, система-клиент должна получить разрешение на доступ к защищенному ресурсу со стороны его владельца. В случае, когда владельцем является пользователь ЕСИА, система-клиент должна направить пользователя на страницу предоставления прав доступа в ЕСИА*(1) (пользователь должен быть предварительно аутентифицирован в ЕСИА или система ЕСИА попросит его пройти идентификацию и аутентификацию).

Эта ссылка должна содержать следующие обязательные параметры:

— — идентификатор системы-клиента (мнемоника системы в ЕСИА);

— — подпись запроса в формате PKCS#7 detached signature в кодировке UTF-8 от значений четырех параметров HTTP-запроса: scope, timestamp, clientId, state (без разделителей). должен быть закодирован в формате base64 url safe. Используемый для проверки подписи сертификат должен быть предварительно зарегистрирован в ЕСИА и привязан к учетной записи системы-клиента в ЕСИА. ЕСИА поддерживает сертификаты в формате X.509. ЕСИА поддерживает алгоритмы формирования электронной подписи RSA с длиной ключа 2048 и алгоритмом криптографического хэширования SHA-256, а также алгоритм электронной подписи ГОСТ Р 34.10-2001 и алгоритм криптографического хэширования ГОСТ Р 34.11-94.

— — ссылка, по которой должен быть направлен пользователь после того, как даст разрешение на доступ к ресурсу;

— — область доступа, т.е. запрашиваемые права; например, если система-клиент запрашивает доступ к сведениям о сотрудниках организации, то scope должна иметь значение http://esia.gosuslugi.ru/org_emps (с необходимыми параметрами); если запрашивается scope http://esia.gosuslugi.ru/id_doc*(2) (данные о пользователе), то не нужно в качестве параметра указывать oid этого пользователя;

— — это тип ответа, который ожидается от ЕСИА, имеет значение code, если система-клиент должна получить авторизационный код;

— — набор случайных символов, имеющий вид 128-битного идентификатора запроса (необходимо для защиты от перехвата), генерируется по стандарту UUID;

— — время запроса авторизационного кода в формате yyyy.MM.dd HH:mm:ss Z (например, 2013.01.25 14:36:11 +0400), необходимое для фиксации начала временного промежутка, в течение которого будет валиден запрос с данным идентификатором ( );

Если в ходе авторизации не возникло ошибок, то ЕСИА осуществляет редирект пользователя по ссылке, указанной в redirect_uri, а также возвращает два обязательных параметра:

— — значение авторизационного кода;

— — значение параметра state, который был получен в запросе на авторизацию; система-клиент должна провести сравнение отправленного и полученного параметра state.

В случае ошибки сервис авторизации вернет в параметре error код ошибки (например, «access_denied») и не перенаправит пользователя по адресу, указанному в redirect_uri. Перечень возможных ошибок приведен в таблице 10.

Таблица 10 — Список ошибок при получении маркеров доступа

Источник

Операция «Зарегистрировать подтверждённую учётную запись в ЕСИА с отправкой пароля для первого входа на контактные данные»

Общие сведения

Описание входных параметров

Параметры комплексного типа описаны в приложении «Описание общих структур данных».

Описание выходных параметров

При успешном завершении в ответном сообщении содержится идентификатор заявки на регистрацию пользователя (requestId), поскольку верификация данных пользователя осуществляется в асинхронном режиме (в силу возможной недоступности БГИР ФОИВ для осуществления верификации персональных данных пользователей).

При неуспешном завершении метод возвращает ошибку, содержащую следующие параметры:

• faultCode– код ошибки (см. п. );
• faultString– текст ошибки.

Коды возвратов

Контрольные примеры

Вызов контрольного примера следует осуществлять только через СМЭВ.

При этом в блоке <wsse:Security soapenv:actor=»http://smev.gosuslugi.ru/actors/smev«> следует указывать действующий сертификат ИС, которая осуществляет вызов сервиса¹⁰.
Запрос

Ответ на запрос в случае успешного исполнения

Получение операторского маркера доступа для управления пользователями

Примечание

Данный сценарий не требует интерактивного взаимодействия Пользователя с Веб-интерфейсом ЦИ DSS.

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

Перед началом интеграции Администратору DSS необходимо:

• Выпустить и зарегистрировать на DSS cертификат аутентификации Оператора DSS
• Зарегистрировать OAuth-клиента

Для получения маркера доступа необходимо выполнить следующие шаги:

Инициация аутентификации

Данный шаг заключается в отправке GET-запроса на аутентификацию на конечную точку /authorize/certificate. Примера запроса представлен ниже.

Пример запроса

• client_id — идентификатор клиента OAuth, зарегистрированный на ЦИ DSS. Для регистрации клиента и его последующей конфигурации можно воспользоваться командлетами Windows PowerShell Add-DssClient и Set-DssClient соответственно.

Примечание

При регистрации клиента параметр AllowedFlow должен включать в себя разрешения AuthorizationCode и ResourceOwner .

• response_type — в данном сценарии имеет значение code .
• scope — области использования маркера. Должен содержать значение dss.
• redirect_uri — зарегистрированный на Центре Идентификации адрес возврата (по этому адресу будет возвращён запрошенный код авторизации).

Примечание

Значение параметра должно соответствовать значению адреса возврата, заданного при регистрации клиента на ЦИ.

Для случаев, в которых не планируется использование выделенного HTTP-сервиса для обработки URI перенаправления, рекомендуется использовать зарезервированный URI urn:ietf:wg:oauth:2.0:oob:auto .

• resource — идентификатор ресурса, для доступа к которому выпускается токен.

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

Параметр client_id в теле запроса должен был заменен на заголовок Auhtorization HTTP-запроса, имеющий значение Basic Base64(client_id:client_secret) .

Также необходимо указать операторский сертификат в качестве клиентского SSL/TLS сертификата, по нему будет осуществляться аутентификация оператора на ЦИ.

Получение кода авторизации

В случае успешной аутентификации

• ответ сервера будет иметь статус HTTP 302
• В заголовке Location будет содержаться код авторизации

В примере используется специальное значение redirect_uri, клиенту необходимо из заголовка Location извлечь значение параметра code. Значение параметра code будет использовано для получения AccessToken на следующем шаге.

Пример ответа

Типовые ошибки

Получение операторского маркера доступа

Для получения маркера доступа используется конечная точка /token. Клиент формирует следующий HTTP-запрос:

• grant_type — в данном сценарии имеет значение authorization_code .
• code — код авторизации, полученный на предыдущем этапе.
• redirect_uri — зарегистрированный на Центре Идентификации адрес возврата (по этому адресу будет возвращён запрошенный код авторизации).

Примечание

Значение параметра должно соответствовать значению адреса возврата, заданного при регистрации клиента на ЦИ.

• client_id — идентификатор клиента OAuth, зарегистрированный на ЦИ DSS.

В случае успешной обработки запроса Центром Идентификации ответ будет содержать:

• access_token — Маркер доступа, выпущенный Центром Идентификации DSS
• token_type — Тип токена
• expires_in — Время жизни токена в секундах

Значение параметра access_token необходимо будет использовать при обращениях к Сервису Подписи.

Примечание

Данный access_token не даёт право Оператору DSS выполнять операции на Сервисе Подписи от имени пользователей. access_token может быть использован для получения Политики Сервиса Подписи.

Получение делегирующего маркера доступа

Для получения AccessToken для делегирования используется конечная точка oauth/token. Подробная информация по протоколу получения AccessToken для делегирования: OAuth 2.0 Token Exchange.

• grant_type — тип разрешения, в данном сценарии равен urn:ietf:params:oauth:grant-type:token-exchange.
• resource – идентификатор Сервиса Подписи.
• actor_token — Маркер доступа, полученный на предыдущем шаге
• actor_token_type – тип маркера доступа, должен иметь значение urn:ietf:params:oauth:token-type:jwt.
• subject_token_type – тип маркера доступа, должен иметь значение urn:ietf:params:oauth:token-type:jwt.
• subject_token – неподписанный JWT-токен, содержащий логин управляемого пользователя.

В декодированном виде subject_token имеет вид:

Пример кодирования JWT-токена можно посмотреть по ссылке.

Первая часть (до точки) называется header, вторая – payload. Для получения закодированного значения необходимо выполнить следующее преобразование:

Примечание

Поле unique_name должно содержать логин пользователя, для которого осуществляется делегация прав.

Поля nbf , exp и iat представляют из себя даты в формате Unix Epoch и задают дату начала действия токена, дату истечения срока действия и дату подписания токена соответственно.

Внимание!

Символ “.” в конце получившегося значения является обязательным.

В заголовке Authorization HTTP-запроса клиент должен передать идентификатор OAuth-клиента и секрет (если используется): Authorization: Basic Base64( : )

Пример запроса

В случае успешной обработки запроса Центром Идентификации ответ будет содержать:

• access_token — делегирующий AccessToken, выпущенный Центром Идентификации DSS
• token_type — Тип токена
• expires_in — Время жизни токена в секундах

Значение параметра access_token необходимо будет использовать при обращениях к Сервису Подписи во время выполнения операции оператором от имени пользователя.

Источник

Приложение В. Сервисы ЕСИА, основанные на протоколе OAUTH2.0 и OPENID CONNECT 1.0

Сервисы ЕСИА, основанные на протоколе OAUTH2.0 и OPENID CONNECT 1.0

В.1 Общие сведения

OAuth 2.0 определяет протокол взаимодействия следующих сторон:

— владелец ресурса (resource owner) — сущность, которая может предоставить доступ к защищаемому ресурсу (например, конечный пользователь);

— система-клиент (client) — приложение, которое запрашивает доступ к защищаемому ресурсу от имени владельца ресурса;

— сервис авторизации (authorization server) — сервис, который выпускает для клиента маркеры доступа с разрешения владельца ресурса;

— поставщик ресурса (resource server) — сервис, на котором размещены защищаемые ресурсы, и который может принимать запросы на доступ к защищаемым ресурсам и отвечать на эти запросы.

Модель контроля доступа, реализуемая сервисом авторизации ЕСИА, основана на использовании маркера доступа (security access token). Этот маркер несет информацию о подмножестве полномочий системы-клиента, о самой системе-клиенте, а также ряд служебных параметров. С точки зрения системы-клиента маркер доступа представляет собой набор символов. Системе-клиенту для получения доступа к защищенным ресурсам (т.е. делать успешные вызовы программного интерфейса), как правило, не требуется расшифровывать маркер доступа, достаточно лишь получать по определенным правилам и корректно использовать. В то же время в ЕСИА предусмотрены и «подписанные» маркеры доступа, которые можно проверить без обращения к ЕСИА.

В ЕСИА используются два способа получения маркера доступа:

1. Система-клиент получает маркер доступа в результате делегированного принятия решения сервисом авторизации на основании согласия владельца ресурса. В этом случае сервис авторизации выдает маркер доступа, если явными # образом получает разрешение со стороны владельца ресурса. Например, система-клиент обратилась к сервису авторизации за маркером, позволяющим получить контактные данные пользователя. В этом случае сервис авторизации запрашивает у пользователя, согласен ли он предоставить данные системе-клиенту, и при позитивном решении выдает маркер доступа.

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

Аутентификация пользователя, реализуемая с помощью модели OAuth 2.0 и распишения OpenID Connect, основана на использовании маркера идентификации (ID token). Этот маркер несет информацию об идентификационных данных пользователя, а также ряд служебных параметров.

В.2 Модель контроля на основе делегированного принятия решения

В.2.1 Общие принципы

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

В общем виде схема взаимодействия выглядит следующим образом:

— система-клиент запрашивает у владельца ресурса разрешение на доступ к соответствующим ресурсам. Обычно этот запрос осуществляется не напрямую к владельцу ресурса, а опосредованно через сервис авторизации (который, в свою очередь, запрашивает разрешение у владельца ресурса), поскольку сам владелец ресурса не может выдать ни маркер доступа, ни авторизационный код;

— система-клиент получает разрешение на доступ (authorization grant) в виде авторизационного кода;

— система-клиент запрашивает маркер доступа, предъявив авторизационный код сервису авторизации;

— сервис авторизации аутентифицирует систему-клиента, проверяет авторизационный код и выдает маркер доступа и маркер обновления;

— система-клиент запрашивает у поставщика защищенный ресурс, предъявляя маркер доступа;

— поставщик ресурса проверяет маркер доступа, если он валиден, то разрешает доступ к защищенному ресурсу;

— система-клиент вновь запрашивает с помощью выданного ранее маркера доступ к защищенному ресурсу;

— поставщик ресурса проверяет маркер, обнаруживает, что срок его действия истек, возвращает сообщение об ошибке;

— система-клиент обращается к сервису авторизации за получением нового маркера доступа, предъявляя маркер обновления;

— сервис авторизации проверяет валидность маркера обновления и возвращает два новых маркера: доступа и обновления.

Схема взаимодействия представлена на рисунке 14.

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

Ключевая особенность этой модели в том, что сам владелец ресурса никогда не получает маркер доступа, его получает сама система-клиент в результате прямой связи с сервисом авторизации (server-side flow).

Рисунок 14 — Общая схема взаимодействия при получении маркера доступа с помощью авторизационного кода

Для оптимизации повторного получения маркера доступа используется механизм маркера обновления (refresh token): в этом случае первоначально в обмен на авторизационный код системе-клиенту выдается не только маркер доступа, но и маркер обновления. Когда маркер доступа перестает действовать, система-клиент обращается к сервису авторизации за получением нового маркера доступа, предъявляя маркер обновления. Сервис авторизации проверяет валидность маркера обновления (что он не был отозван и что срок его действия не истек) и выдает новый маркер доступа и маркер обновления.

Особенности маркера обновления:

— имеет более длительный (или бессрочный) срок действия, чем у маркера доступа;

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

— выдается сервисом авторизации одновременно с маркером доступа;

— может быть отозван владельцем ресурса.

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

В.2.2 Получение авторизационного кода

Чтобы получить авторизационный код, система-клиент должна получить разрешение на доступ к защищенному ресурсу со стороны его владельца. В случае, когда владельцем является пользователь ЕСИА, система-клиент должна направить пользователя на страницу предоставления прав доступа в ЕСИА*(1) (пользователь должен быть предварительно аутентифицирован в ЕСИА или система ЕСИА попросит его пройти идентификацию и аутентификацию).

Эта ссылка должна содержать следующие обязательные параметры:

— — идентификатор системы-клиента (мнемоника системы в ЕСИА);

— — подпись запроса в формате PKCS#7 detached signature в кодировке UTF-8 от значений четырех параметров HTTP-запроса: scope, timestamp, clientId, state (без разделителей). должен быть закодирован в формате base64 url safe. Используемый для проверки подписи сертификат должен быть предварительно зарегистрирован в ЕСИА и привязан к учетной записи системы-клиента в ЕСИА. ЕСИА поддерживает сертификаты в формате X.509. ЕСИА поддерживает алгоритмы формирования электронной подписи RSA с длиной ключа 2048 и алгоритмом криптографического хэширования SHA-256, а также алгоритм электронной подписи ГОСТ Р 34.10-2001 и алгоритм криптографического хэширования ГОСТ Р 34.11-94.

— — ссылка, по которой должен быть направлен пользователь после того, как даст разрешение на доступ к ресурсу;

— — область доступа, т.е. запрашиваемые права; например, если система-клиент запрашивает доступ к сведениям о сотрудниках организации, то scope должна иметь значение http://esia.gosuslugi.ru/org_emps (с необходимыми параметрами); если запрашивается scope http://esia.gosuslugi.ru/id_doc*(2) (данные о пользователе), то не нужно в качестве параметра указывать oid этого пользователя;

— — это тип ответа, который ожидается от ЕСИА, имеет значение code, если система-клиент должна получить авторизационный код;

— — набор случайных символов, имеющий вид 128-битного идентификатора запроса (необходимо для защиты от перехвата), генерируется по стандарту UUID;

— — время запроса авторизационного кода в формате yyyy.MM.dd HH:mm:ss Z (например, 2013.01.25 14:36:11 +0400), необходимое для фиксации начала временного промежутка, в течение которого будет валиден запрос с данным идентификатором ( );

Если в ходе авторизации не возникло ошибок, то ЕСИА осуществляет редирект пользователя по ссылке, указанной в redirect_uri, а также возвращает два обязательных параметра:

— — значение авторизационного кода;

— — значение параметра state, который был получен в запросе на авторизацию; система-клиент должна провести сравнение отправленного и полученного параметра state.

В случае ошибки сервис авторизации вернет в параметре error код ошибки (например, «access_denied») и не перенаправит пользователя по адресу, указанному в redirect_uri. Перечень возможных ошибок приведен в таблице 10.

Таблица 10 — Список ошибок при получении маркеров доступа

Источник

«Методические рекомендации по использованию Единой системы идентификации и аутентификации. Версия 2.84»
(приложение 17 к протоколу заседания Подкомиссии по использованию информационных технологий при предоставлении государственных и муниципальных услуг Правительственной комиссии по использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 13.05.2016 N 168пр)

Вы можете заказать документ на e-mail

foke	#1 Оставлено : 31 мая 2022 г. 22:02:42(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 31.05.2022(UTC) Сообщений: 1	Здравствуйте. В версии ЕСИА 2.90 депрекейтнули эндпоинт для получения кода авторизации /aas/oauth2/ac. Новая версия: /aas/oauth2/v2/ac. Изменилось описание формирования параметра client_secret. До версии 2.90: Цитата: <client_secret> – подпись запроса в формате PKCS#7 detached signature в кодировке UTF- 8 от значений четырех параметров HTTP–запроса: scope, timestamp, clientId, state (без разделителей). <client_secret> должен быть закодирован в формате base64 url safe Версия 2.90: Цитата: <client_secret> — подпись значений пяти параметров в кодировке UTF-8: client_id, scope, timestamp, state, redirect_uri. конкатенировать вышеуказанные параметры; подписать полученную строку с использованием алгоритма подписания data hash с использованием механизмов КриптоПРО CSP и сертификата информационной системы; закодировать полученное значение в URL Safe Base64. В версии <2.90 с «подпись запроса в формате PKCS#7 detached signature» разобрались, работает. В версии 2.90 неясно, что такое «подписать полученную строку с использованием алгоритма подписания data hash с использованием механизмов КриптоПРО CSP»? Формулировка весьма расплывчатая, на мой взгляд. Должен ли измениться код формирования подписи? «data hash» — это название алгоритма? Есть ли рабочий java-код под эту задачу? Использование прежнего java-кода формирования подписи параметра client_secret (с учётом прочих обновлений параметров, описанных в инструкции) приводит к ошибке «ESIA-007005: The client is not authorized to request an access token using this method.», что по моему опыту соответствует некорректно сформированному client_secret. На данный момент сгенерированный url получения кода авторизации выглядит следующим образом: Цитата: https://esia-portal1.test.gosuslugi.ru/aas/oauth2/v2/ac ?client_id=MY-SYSTEM &client_certificate_hash=последовательность-64-символа &scope=fullname%20gender%20birthdate%20birthplace%20birth_cert_doc%20contacts%20inn%20snils%20residence_doc%20temporary_residence_doc%20id_doc%20temporary_residence_doc &response_type=code &access_type=offline &client_secret=последовательность-4-тысячи-символов &state=265133f8-0aaf-4c7a-89e2-b50fc6e0318a &timestamp=2022.05.31+23%3A10%3A39+%2B0400 &redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Flogin%2Foauth2%2Fcode%2Fesia Отредактировано пользователем 31 мая 2022 г. 22:15:29(UTC)  | Причина: Не указана

saaremaa	#2 Оставлено : 6 июля 2022 г. 13:50:13(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 06.07.2022(UTC) Сообщений: 6	У вас получилось что-нибудь с получением кода авторизации? Тоже зависли на этом моменте и не знаем куда двигаться. Поддержка Минцифры только пересылает отрывки из методички. Дополнение от 07.07.2022: Цитата: К Вашему запросу SCR#2946679 добавлен комментарий: Добрый день! По Вашему обращению сообщаем, что при формировании client_secret необходимо использовать следующие алгоритмы шифрования: GOST3411_2012_256withGOST3410_2012_256; GOST3411_2012_512withGOST3410_2012_512: GOST3411withGOST3410EL . Кто добавил: СКУФ Служебный/ПУБЛИЧНОЕ АКЦИОНЕРНОЕ ОБЩЕСТВО «РОСТЕЛЕКОМ» после формирования подписи с помощью GOST3411_2012_256withGOST3410_2012_256 получили корректный client_secret Библиотеки на языке Golang: https://github.com/Theo730/gogost Описание: http://www.gogost.cypherpunks.ru/ Отредактировано пользователем 7 июля 2022 г. 13:01:22(UTC)  | Причина: Не указана

two_oceans	#3 Оставлено : 8 июля 2022 г. 8:06:58(UTC)
Статус: Эксперт Группы: Участники Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,599 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 389 раз в 364 постах	Автор: saaremaa По Вашему обращению сообщаем, что при формировании client_secret необходимо использовать следующие алгоритмы шифрования: GOST3411_2012_256withGOST3410_2012_256; GOST3411_2012_512withGOST3410_2012_512: GOST3411withGOST3410EL . Добрый день. Сначала конечно замечание, что не шифрования, а подписания, так как в сообщениях выше процитированы места, где ясно говорится «подпись», «подписать». 1) Если перевести идентификаторы на человекопонятный язык, то это ГОСТ-2012 (256 и 512 бит), ГОСТ-2001. Насчет актуальности последнего весьма сомнительно, так как сертификаты гост-2001 уже должны были все закончиться. Для вышеуказанных идентификаторов нужно на подписание передавать сами данные, а не вычисленный заранее хэш. 2) Если речь про PKCS#7, то там нет проблемы с порядком байтов, все определено в стандарте. Если же речь про RawSignature, то стандарт не определяет порядок байт, может понадобится «переворачивать/отзеркалить» значение хэша и/или подписи (первый байт с последним, второй с предпоследним и т.д) до кодирования BASE64, так как указанные идентификаторы без слова «CryptoPro», что подразумевает порядок байт Big Endian. Обычно достаточно перевернуть значение подписи. В то же время есть идентификаторы гост-2012 со словом «CryptoPro», которые подразумевает порядок байт Little Endian — то есть переворотов не нужно. 3) Важно также не забывать, что URL Safe Base64 не то же самое, что BASE64, нужно заменить ряд символов, имеющих специальное значение в URL. Что же до указанной ссылки на библиотеку Го, похоже на несертифицированное решение с самостоятельной реализацией криптографических примитивов. Для тестов с тестовыми ключами конечно никто Вам ничего особо не скажет. Используя же несертифицированное решение с гитхаба в продакшене с «боевыми» ключами, Вы принимаете на себя риски возможных штрафов за неправильное обращение со СКЗИ и ключевой информацией. Будьте бдительны, не все работающие решения можно использовать по закону.

forumname	#4 Оставлено : 23 августа 2022 г. 9:44:46(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 23.08.2022(UTC) Сообщений: 1	Автор: foke подписать полученную строку с использованием алгоритма подписания data hash с использованием механизмов КриптоПРО CSP Я правильно понимаю, что сначала вычисляем hash с помощью алгоритма GOST3411_2012_256, а потом подписываем вычисленное значение алгоритмом GOST3410_2012_256? Или нужно как-то иначе использовать механизмы КриптоПро CSP?

navrocky	#5 Оставлено : 19 октября 2022 г. 13:52:15(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 19.10.2022(UTC) Сообщений: 12 Сказал(а) «Спасибо»: 2 раз Поблагодарили: 2 раз в 2 постах	Вот рабочий код на Java для формирования client_secret с использованием крипто-провайдера BouncyCastle: Код: PrivateKey privateKey = ...; String joinedString = String.join("", clientId, scope, timeStamp, state, redirectUri); Signature signer = Signature.getInstance("GOST3411WITHECGOST3410-2012-256", new BouncyCastleProvider()); signer.initSign(privateKey); signer.update(joinedString.getBytes()); signature = signer.sign(); String clientSecret = Base64.getUrlEncoder().encodeToString(signature); Отредактировано пользователем 19 октября 2022 г. 13:53:54(UTC)  | Причина: Не указана
1 пользователь поблагодарил navrocky за этот пост.	JsutUser оставлено 11.11.2022(UTC)

EugeneNSK	#6 Оставлено : 19 декабря 2022 г. 11:26:02(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 25.11.2020(UTC) Сообщений: 14 Откуда: NSK Сказал(а) «Спасибо»: 3 раз	Автор: navrocky Вот рабочий код на Java для формирования client_secret с использованием крипто-провайдера BouncyCastle: Код: PrivateKey privateKey = ...; String joinedString = String.join("", clientId, scope, timeStamp, state, redirectUri); Signature signer = Signature.getInstance("GOST3411WITHECGOST3410-2012-256", new BouncyCastleProvider()); signer.initSign(privateKey); signer.update(joinedString.getBytes()); signature = signer.sign(); String clientSecret = Base64.getUrlEncoder().encodeToString(signature); Тоже столкнулся с проблемой формирования client_secret при получении кода доступа (через v2/ac). Подпись действительно стала сырой. Приведенный выше код рабочий. Для JCP/JCSP использую: Код: String joinedString = String.join("", clientId, scope, timeStamp, state, redirectUri); AlgorithmDetails algorithmDetails = new AlgorithmDetails(privateKey.getAlgorithm()); Signature signature = Signature.getInstance(algorithmDetails.getSignAlgorithm(), provider); signature.initSign(privateKey); signature.update(joinedString.getBytes()); byte[] result = signature.sign(); String clientSecret = new String(Base64.getUrlEncoder().encode(result), StandardCharsets.UTF_8);

dzibzeev	#7 Оставлено : 29 марта 2023 г. 17:25:28(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 28.03.2023(UTC) Сообщений: 1	Коллеги! А у кого-нибудь получилось с использованием cryptcp -signf подписать секрет клиента для второй версии API(v2/ac) ЕСИА? Вот так мы сейчас создаем подпись для ЕСИА(код на go): command := exec.Command(s.cmd, «-signf», «-der», «-strict», «-cert», «-hashalg», s.hashAlgOID, «-detached», «-thumbprint», s.thumbprint, «-pin», s.containerPIN, filename) С первой версией все прекрасно работает, с v2 не хочет работать. ЕСИА возвращает ошибку ESIA-007053: OAuthErrorEnum.clientSecretWrong

MESHOK	#8 Оставлено : 21 июня 2023 г. 12:25:31(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 21.06.2023(UTC) Сообщений: 1	Находите имя своего ключа: csptest -keys -enum_cont -verifycontext -fqcn Подписываете строку: csptest -keys -cont ‘\\.\<хранилище>\<имя _контейнера>’ -sign GOST12_256 -in файл_с_данными -out файл_с_данными.sig -keytype exchange Прочитываете файл в бинарном виде и побайтово его переворачиваете. Например: Исходные данные: 68 65 6c 6c 6f Перевернутые данные: 6f 6c 6c 65 68 Перевернутые данные кодируете в base64url — это и есть client_secret

saaremaa	#9 Оставлено : 4 сентября 2023 г. 20:40:58(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 06.07.2022(UTC) Сообщений: 6	Коллеги, поделитесь решением. Как подписать через КриптоПро строку client_secret для получения авторизационного кода через https://esia-portal1.tes…lugi.ru/aas/oauth2/v2/ac ??? По возможности примерами к командной строке. Если есть кусок кода на Golang — это просто будет чудесно. Все что выше перепробовали — получаем ошибку ESIA-007053. При этом самописное решение работает, но использовать его нельзя в боевой системе.

Андрей *	#10 Оставлено : 4 сентября 2023 г. 21:44:08(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,134 Сказал «Спасибо»: 460 раз Поблагодарили: 1950 раз в 1508 постах	Автор: saaremaa Коллеги, поделитесь решением. Как подписать через КриптоПро строку client_secret для получения авторизационного кода через https://esia-portal1.tes…lugi.ru/aas/oauth2/v2/ac ??? По возможности примерами к командной строке. Если есть кусок кода на Golang — это просто будет чудесно. Все что выше перепробовали — получаем ошибку ESIA-007053. При этом самописное решение работает, но использовать его нельзя в боевой системе. а этот ответ с примером команды уже проверили?
Техническую поддержку оказываем тут Наша база знаний
	WWW

Быстрый переход
 

Вы не можете создавать новые темы в этом форуме.

Вы не можете отвечать в этом форуме.

Вы не можете удалять Ваши сообщения в этом форуме.

Вы не можете редактировать Ваши сообщения в этом форуме.

Вы не можете создавать опросы в этом форуме.

Вы не можете голосовать в этом форуме.

We appreciate your report. Unfortunately, a special account is needed in order to sign-in. (account creation requires valid data)

If the reporter (or anyone else) can do a more in depth test and provide more information (console logs/errors/screenshots) regarding this issue, feel free to reopen and leave a comment (or you can send us an email with the test account credentials and we will test it on our own).

Suggestions:
• Clear cache/data/cookies, disable Ad-blocker (if available), or use a clean profile and check again
• If there are any changes made to the default settings of the browser (e.g. in about:config), please revert to the default settings

Closing this as incomplete due to a lack of valid credentials.

[qa_20/2023]