Стандарт Банка России «Безопасность финансовых (банковских) операций. Прикладные программные интерфейсы обеспечения безопасности финансовых сервисов на основе протокола OpenID. Требования» СТО БР ФАПИ.СЕК-1.6-2020

5.4.3.6. При использовании гибридного сценария запрос токена клиентом, проверка запроса токена, генерация токена доступа и ID токена на конечной точке токена, их проверка клиентом, а также реакция на ошибки выполняются в соответствии с аналогичными действиями в сценарии с генерацией кода авторизации (см. подпункты 5.4.2.11 - 5.4.2.15).

Если ID токен возвращается как из конечной точки авторизации, так и из конечной точки токена, что имеет место для одного из двух значений <response_type>: «code id_token» и «code id_token token», значения и  _{должны быть идентичны в обоих ID токенах. Все значения параметров события аутентификации, присутствующие в любом из них, должны присутствовать в обоих ID токенах. Если какой-либо ID токен содержит параметр конечного пользователя, присутствующий в обоих ID токенах, он должен иметь одинаковые значения в обоих ID токенах. Сервер авторизации может вернуть меньшее количество параметров о конечном пользователе из конечной точки авторизации, например по соображениям конфиденциальности.}

Примечание. Дополнительные сведения о гибридном сценарии аутентификации приведены в [11] (подраздел 3.3).

5.4.4. Регистрация сервера авторизации (Discovery) и динамическая регистрация клиента

5.4.4.1. Прежде чем запустить сервис аутентификации и авторизации клиентов, сервер авторизации должен опубликовать свои метаданные, описывающие его адрес и параметры доступа в ходе процедуры OpenID Connect Discovery.

5.4.4.2. Настоящий стандарт не регламентирует способ получения адреса сервера авторизации. Этот адрес может предоставляться клиенту, например указанием его в документации на систему. Сервер авторизации может также запускать сервис, поддерживающий технологию WebFinger [25].

5.4.4.3. Клиент может, используя HTTP GET запрос по адресу сервера авторизации, получить конфигурацию сервера авторизации (документ Discovery), в которой в JSON формате перечислены метаданные сервера авторизации. В частности, в конфигурации перечислены значения таких параметров:

• : (обязательный) https URL адрес, являющийся идентификатором эмитента (Issuer Identifier); далее это значение должно быть указано в качестве параметра в ID токенах; получив ответ, клиент должен проверить совпадение значения параметра с адресом сервера авторизации, на который он делал запрос;
• : (обязательный) URI конечной точки авторизации (см. подпункты 5.4.2.2 - 5.4.2.9); может включать в себя компоненту запроса в формате «application/x-www-form-urlen-coded»; не должен включать компоненту фрагмента;
• <token_endpoint>: (обязательный кроме неявного сценария) URI конечной точки токена (см. подпункты 5.4.2.10 - 5.4.2.14); может включать в себя компоненту запроса в формате «application/x-www-form-urlencoded»; не должен включать компоненту фрагмента;
• <userinfo_endpoint>: (рекомендуемый) URI конечной точки UserInfo, предназначенный для запроса информации об аутентифицированном конечном пользователе (см. подпункт 5.4.2.20);
• <registration_endpoint>: (рекомендуемый) URI конечной точки динамической регистрации клиентов сервера авторизации (см. подпункт 5.4.4.5);
• <jwks_uri>: (обязательный) URL документа Key Set (см. подпункт 5.7.3.3) сервера авторизации, где публикуются его ключи в формате JWK; публикуемые сертификаты должны передаваться доверенным образом;
• <grant_types_supported>: (опциональный) перечень поддерживаемых сервером авторизации типов разрешений на доступ (grants); сервера авторизации OIDC должны поддерживать значения «authorization_code» и «implicit»; по умолчанию используется значение [«authorization_code», «implicit»];
• <scopes_supported>: (рекомендуемый) JSON массив значений параметра , которые поддерживает сервер авторизации;
• <response_types_supported>: (обязательный) JSON массив с перечнем поддерживаемых значений параметра <response_type>; сервера авторизации OIDC должны поддерживать значения «code», «id_token» и «token id_token»;
• <response_modes_supported>: (опциональный) JSON массив с перечнем поддерживаемых значений параметра <response_mode>; по умолчанию [«query», «fragment»]; также в подразделе 8.3 приведен перечень значений <response_mode>, связанный с использованием технологии JARM;
• <claims_supported>: (рекомендуемый) JSON массив, содержащий список имен параметров, значения которых сервер авторизации может предоставить клиенту;
• service_documentation: (опциональный) URL-адрес страницы, содержащей читаемую информацию, которая представляется разработчиками или которую нужно знать при использовании сервера авторизации. В частности, если сервер авторизации не поддерживает динамическую регистрацию клиентов, в этой документации должна быть представлена информация о том, как регистрировать клиентов.

В подразделе 8.3 приведен перечень дополнительных метаданных сервера авторизации, связанных с использованием технологии JARM.

Адреса всех перечисленных выше конечных точек сервера авторизации должны быть разными.

Примечание. Дополнительные сведения о протоколе Discovery представлены в документах [26] и RFC 8414 [27].

5.4.4.4. Передача сообщений Discovery, в том числе и сообщений сервиса WebFinger, между клиентом и сервером авторизации должна быть защищена с помощью протокола TLS с обеспечением конфиденциальности и целостности. При этом должна выполняться аутентификация источника информации Discovery.

5.4.4.5. Процедура динамической регистрации клиента выполняется после того, как выполнена регистрация сервера авторизации, описанная выше.

Для регистрации клиент посылает HTTP POST запрос серверу авторизации на конечную точку регистрации клиентов (параметр <registration_endpoint> документа Discovery, см. подпункт 5.4.4.1) с типом содержимого «application/json», в котором указываются следующие метаданные клиента:

• <redirect_uris>: (обязательный) перечень поддерживаемых адресов переадресации клиента; одно из этих зарегистрированных значений URI переадресации должно точно соответствовать значению параметра <redirect_uri>, используемому в каждом запросе авторизации;
• <response_types>: (опциональный) JSON массив, содержащий перечень поддерживаемых клиентом типов ответа (см. подпункт 5.4.2.2); по умолчанию — значение «code»;
• <grant_types>: (опциональный) JSON массив, содержащий перечень поддерживаемых клиентом типов разрешений на доступ (grants) из перечня: «authorization_code», «implicit», «refresh_token»; по умолчанию используется значение «authorization_code»;
• : (опциональный) тип клиента («native» или «web»);
• : (опциональный) массив адресов электронной почты лиц, ответственных за этого клиента;
• <client_name>: (опциональный) имя клиента; оно будет показано конечному пользователю при запросе авторизации;
• <logo_uri>: (опциональный) URL ссылка на логотип клиентского приложения; если присутствует, сервер должен отображать это изображение конечному пользователю во время запроса авторизации;
• <client_uri>: (опциональный) URL домашней страницы клиента; если присутствует, сервер должен отображать этот URL-адрес конечному пользователю;
• <policy_uri>: (опциональный) URL-адрес, который клиент предоставляет конечному пользователю с информацией о том, как будут использоваться данные его профиля; если присутствует, сервер авторизации должен показать этот URL-адрес конечному пользователю;
• <tos_uri>: (опциональный) URL-адрес, который клиент предоставляет конечному пользователю для ознакомления с условиями обслуживания клиента; если присутствует, сервер авторизации должен показать этот URL-адрес конечному пользователю;
• <jwks_uri>: (опциональный) URI документа JWK Set (см. подпункт 5.7.3.3), содержащего ключи клиента в формате JWK; публикуемые сертификаты должны передаваться доверенным образом;
• : (опциональный) документ JWK Set, передаваемый по значению; параметры <jwks_uri> и  не должны одновременно присутствовать в метаданных клиента; сертификаты открытых ключей должны передаваться доверенным образом;
• <default_max_age>: (опциональный) максимальный возраст аутентификации по умолчанию; указывает, что конечный пользователь должен быть повторно аутентифицирован, если с момента его аутентификации прошло более чем указанное количество секунд;
• <require_auth_time>: (опциональный) логическое значение, указывающее, требуется ли указывать параметр в ID токене; значением по умолчанию является «false»;
• <token_endpoint_auth_method>: (опциональный) поддерживаемый метод аутентификации клиента на конечной точке токена; возможные варианты: «client_secret_post», «client_secret_ basic»,«client_secret_jwt»,«private_key_jwt», «tls_client_auth», «self_signed_tls_client_auth» и «none» (см. подраздел 5.5).

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

В случае если все запрошенные значения параметров клиента корректны, сервер авторизации должен, используя код HTTP 201, возвратить клиенту JSON документ с типом содержимого «application/json» со следующей информацией:

• <client_id>: (обязательный) уникальный идентификатор клиента, который далее будет использоваться клиентом в протоколах OIDC;
• <client_secret>: (опциональный) конфиденциальная информация, которая возвращается конфиденциальным клиентам и используется для аутентификации клиента сервером авторизации, а также для защиты взаимодействия клиента и сервера авторизации; значение этого параметра обязательно при использовании механизма аутентификации клиента <client_secret_jwt>;
• <client_id_issued_at>: (опциональный) время выдачи идентификатора клиента; значение представляет собой число, представляющее количество секунд от 1970-01-01T0:0:0Z UTC до текущего момента;
• <client_secret_expires_at>: (обязательный, если присутствует <client_secret>) время окончания действия <client_secret> или 0, если он не устаревает никогда; значение представляет собой число, представляющее количество секунд от 1970-01-01T0:0:0Z UTC до текущего момента.

Кроме того, сервер авторизации возвращает клиенту в составе ответа метаданные клиента, принятые сервером в запросе регистрации.

Должна быть обеспечена конфиденциальность передачи значения параметра <client_secret>. Механизм защиты должен быть определен на этапе разработки сервера авторизации.

5.4.4.7. При ошибке обработки запроса регистрации (см. подпункт 5.4.4.6) сервер авторизации не выполняет регистрацию клиента, а конечная точка регистрации возвращает клиенту код состояния HTTP 400, включая JSON объект, описывающий ошибку в теле ответа.

JSON объект, описывающий ошибку, содержит два обязательных параметра и <error_description> в формате подпункта 5.4.2.9. Коды ошибки:

• «invalid_redirect_uri»: значение одного или нескольких значений массива <redirect_uris> недопустимо;
• «invalid_client_metadata»: значение одного из полей метаданных клиента недопустимо, и сервер отклонил этот запрос.

Примечание. Дополнительные сведения о динамической регистрации клиента приведены в документах [28] и [29].

5.4.4.8. Передача информации между клиентом и конечной точкой регистрации сервера авторизации должна быть защищена с помощью протокола TLS с аутентификацией сервера авторизации.

5.5. АУТЕНТИФИКАЦИЯ КЛИЕНТА

5.5.1. При динамической регистрации (см. подпункт 5.4.4.5) клиент может зарегистрировать метод аутентификации клиента, указав его идентификатор в качестве значения параметра <token_endpoint_auth_ method>. Если этот метод не зарегистрирован, по умолчанию используется метод «client_secret_basic». Можно использовать следующие варианты механизмов аутентификации:

• «client_secret_basic»: аутентификация с использованием базовой схемы аутентификации HTTP и <client_secret>;
• «client_secret_post»: аутентификация с включением учетных данных клиента в тело запроса и с использованием <client_secret>;

Примечание. Спецификации механизмов «client_secret_basic» и «client_secret_post» представлены в [10] (пункт 2.3.1).

• «client_secret_jwt»: аутентификация с использованием структуры JWT на основе кода аутентификации HMAC и <client_secret> (см. пункт 5.5.2);
• «private_key_jwt»: аутентификация с использованием структуры JWT на основе цифровой подписи (см. пункт 5.5.3);
• «tls_client_auth»: аутентификация с использованием TLS с взаимной аутентификацией и PKI для связывания сертификата с клиентом (см. пункт 5.5.4);
• «self_signed_tls_client_auth»: аутентификация с использованием TLS с взаимной аутентификацией и самоподписанного сертификата клиента (см. пункт 5.5.5);
• «none»: клиент не аутентифицирует себя в конечной точке токена либо потому, что он использует только неявный сценарий аутентификации (и поэтому не использует конечную точку токена), либо потому, что он является публичным клиентом без <client_secret>, либо используется другой механизм аутентификации.

В реализациях настоящего стандарта допускается использование механизмов аутентификации клиента «client_secret_basic», «client_secret_post» и «none» только в тестовом режиме.

5.5.2. Механизм аутентификации «client_secret_jwt»

Клиент, получивший при регистрации значение <client_secnet> от сервера авторизации, создает токен JWT, используя для обеспечения его целостности алгоритмы вычисления кода аутентификации сообщения HMAC на основе хэш-функции и значение <client_secret> в качестве ключа.

Данный механизм использует следующие параметры JWT (см. пункт 5.7.4):

• : (обязательный) источник; должен содержать <client_id> клиента;
• _{: (обязательный) субъект; должен содержать <client_id> клиента;}
• : (обязательный) аудитория; значением должен быть URL-адрес конечной точки токена сервера авторизации;
• : (обязательный) идентификатор JWT; уникальный идентификатор токена, который необходим для предотвращения повторного использования токена;
• : (обязательный) время, по истечении которого токен не должен быть принят к обработке;
• : (опциональный) время выпуска JWT.

Токен JWT должен быть отправлен клиентом серверу авторизации в качестве значения параметра <client_assertion>. Значение параметра <client_assertion_type> должно быть «urn:ietf:params:-oauth: client-assertion-type:jwt-bearer». Эти параметры передаются в качестве утверждений (assertions) методом HTTP POST в адрес конечной точки авторизации с типом содержимого «application/x-www-form-urlencoded».

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

1 JWT должен содержать значение параметра (эмитент).

2 JWT должен содержать значение параметра _{(субъект), идентифицирующего субъект JWT. Для аутентификации клиента это значение должно совпадать с <client_id> клиента.}

3 JWT должен содержать значение параметра (аудитория), которое идентифицирует сервер авторизации как предполагаемую аудиторию. В качестве значения элемента может использоваться URL-адрес конечной точки токена сервера авторизации. Сервер авторизации должен отклонить JWT, который не содержит своего идентификатора в качестве аудитории.

4 JWT должен содержать значение параметра (время действия), ограничивающее временное окно, в течение которого JWT может отслеживаться. Сервер авторизации должен отклонить любой JWT с истекшим временем действия при условии допустимого расхождения часов. Сервер авторизации может отклонить JWT с необоснованно большим значением параметра .

5 JWT может содержать значение параметра (не ранее), определяющее время, до которого токен не должен приниматься для обработки.

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

7 JWT может содержать значение параметра (JWT ID), которое предоставляет уникальный идентификатор токена. Сервер авторизации может гарантировать, что JWT не будут воспроизведены, поддерживая набор используемых значений в течение определенного промежутка времени, в течение которого JWT будет считаться действительным, на основе применимого момента .

8 JWT может содержать другие параметры.

9 JWT должен иметь цифровую подпись или MAC, применяемый эмитентом. Сервер авторизации должен проверить подпись JWT как JWS и отклонить JWT с недопустимой подписью или MAC.

В случае ошибки проверки JWT сервер авторизации должен ответить кодом ошибки «invalid_client» в качестве значения параметра (см. подпункт 5.4.2.9). В случае успешной проверки JWT клиент считается аутентифицированным.

Примечание. Дополнительные сведения о данном методе аутентификации приведены в RFC 7521 [30] и RFC 7523 [31].

Для обеспечения безопасности передачи сообщений аутентификации клиента должен использоваться протокол TLS.

5.5.3. Механизм аутентификации «private_key_jwt»

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

5.5.4. Механизм аутентификации с использованием TLS с взаимной аутентификацией и PKI

Механизм аутентификации клиента с использованием TLS с взаимной аутентификацией и PKI требует выполнения следующих действий.

1 В ходе динамической регистрации (см. подпункт 5.4.4.5) клиент должен получить у сервера авторизации идентификатор <client_id>.

2 В ходе динамической регистрации клиент должен зарегистрировать механизм аутентификации «tls_client_auth».

3 В ходе динамической регистрации клиент должен зарегистрировать ровно одно из имен субъекта сертификата клиента в качестве значения одного из следующих параметров:

• <tls_client_auth_subject_dn>: отличительное имя субъекта сертификата;
• <tls_client_auth_san_dns>: значение записи SAN dNSName в сертификате;
• <tls_client_auth_san_uri>: значение записи SANiformResourceIdentifier в сертификате;
• <tls_client_auth_san_ip>: IP-адрес IPv4 или IPv6 из записи iPAddress SAN в сертификате;
• <tls_client_auth_san_email>: значение записи SAN rfc822Name в сертификате.

4 У клиента должен быть установлен сертификат открытого ключа формата X.509, в котором указано одно отличительное имя субъекта (subject distinguished name, DN) и одно альтернативное имя субъекта (SAN). Сертификат должен успешно проходить процедуру валидации цепочки сертификатов.

Примечание. Общие требования к процедуре валидации цепочки сертификатов открытого ключа формата X.509 приведены в RFC 5280 [32].

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

6 Сервер авторизации на основании предъявленного значения <client_id> должен извлечь из данных регистрации клиента его имя (см. перечисление в пункте 3 данного списка) и сравнить с именем, полученным из предъявленного сертификата. В случае совпадения имен принимается решение об успешном прохождении аутентификации клиента. Иначе сервер авторизации должен ответить кодом ошибки «invalid_client».

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

5.5.5. Механизм аутентификации с использованием TLS с взаимной аутентификацией и самоподписанного сертификата клиента

MTLS-аутентификация клиента с использованием самоподписанного сертификата (подписан ключом подписи клиента, соответствующим ключу проверки подписи в составе сертификата) требует выполнения следующих действий:

1 В ходе динамической регистрации клиент должен зарегистрировать механизм аутентификации «self_signed_tls_client_auth».

2 В ходе динамической регистрации клиент должен зарегистрировать свои самоподписанные сертификаты формата X.509, либо непосредственно публикуя их в качестве значения параметра в формате JWK Set (см. подпункт 5.7.3.3), либо указывая в качестве значения параметра <jwks_uri> ссылку на доверенный источник, содержащий его сертификаты в формате JWK Set.

3 Во время установления TLS-соединения сервер авторизации должен запросить сертификат клиента, проверить его валидность, а также выполнить проверку владения клиентом закрытым ключом, соответствующим открытому ключу, представленному в сертификате. В отличие от метода PKI (см. пункт 5.5.4) цепочка сертификатов клиента в этом случае не проверяется сервером авторизации.

4 Клиент успешно аутентифицируется, если сертификат, который он представил во время установления TLS-соединения, соответствует одному из сертификатов, зарегистрированных для этого клиента (см. перечисление в пункте 2 данного списка).

Метод самоподписанного сертификата позволяет использовать MTLS для аутентификации клиентов без необходимости поддерживать PKI. При использовании вместе с <jwks_uri> клиента он также позволяет клиенту обновлять свои сертификаты X.509 без необходимости изменять свои аутентификационные данные.

5.6. ДОСТУП К ЗАЩИЩЕННОМУ РЕСУРСУ

5.6.1. Доступ клиента к защищенному ресурсу обеспечивает сервер ресурсов. Выполняя запрос, клиент передает ему полученный от сервера авторизации токен доступа. Сервер ресурса проверяет этот токен доступа: его срок действия, присутствие запрашиваемого ресурса в области действия токена. При этом предполагается использование связи сервера ресурса с сервером авторизации.

5.6.2. При запросе защищенного ресурса токен доступа может быть передан клиентом серверу ресурса в заголовке авторизации HTTP (Authorization Request Header). В этом случае значение заголовка должно иметь формат:

где - значение токена доступа в кодировании Base64url.

Примечание. Спецификации структуры и алгоритмов работы с заголовком авторизации HTTP приведены в RFC 2617 [33] (раздел 2).

Клиенту рекомендуется использовать этот метод авторизации. Сервер ресурса должен его поддерживать.

5.6.3. Альтернативный вариант передачи токена доступа от клиента серверу ресурса — в теле HTTP-запроса как значение параметра . При этом должны быть выполнены следующие условия:

• поле заголовка HTTP-запроса имеет значение «application/x-www-form-urlencoded»;
• тело запроса соответствует требованиям кодирования контента «application/x-www-form-urlencoded»;
• тело HTTP-запроса состоит из одной части, то есть запрос не является запросом типа «multipart/form-data»;
• содержимое тела запроса должно состоять исключительно из ASCII-символов;
• должен использоваться HTTP метод, семантика тела запроса которого строго определена. В частности, это означает, что HTTP метод GET не должен использоваться.

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

Примечание. Дополнительные сведения о протоколе доступа клиента к защищенному ресурсу с использованием токена доступа приведены в RFC 6750 [13].

5.6.4. Канал передачи информации между клиентом и сервером ресурса должен быть защищен с помощью протокола TLS с обеспечением конфиденциальности и целостности.

5.7. JWT

5.7.1. Цифровая подпись в формате JSON

5.7.1.1. JWS (JSON Web Signature) — структура данных в формате JSON, представляющая сообщение с цифровой подписью или кодом аутентификации сообщений.

5.7.1.2 JWS состоит из трех частей:

• : JOSE заголовок — JSON-объект, содержащий параметры, описывающие криптографические операции и их параметры (см. подпункт 5.7.1.4);
• : функциональное содержимое JWS (полезная нагрузка) — последовательность октетов, подлежащих защите, другими словами — сообщение; функциональное содержимое может состоять из произвольной последовательности октетов;
• : цифровая подпись или код аутентификации сообщений, вычисленные на основе защищенного заголовка JWS и функционального содержимого JWS.

Заголовок JWS состоит из двух частей:

• : защищенный заголовок JWS — JSON-объект, содержащий параметры заголовка, целостность которых защищена цифровой подписью JWS или операцией MAC;
• : незащищенный заголовок JWS — JSON-объект, который содержит параметры заголовка, целостность которых не обеспечивается.

5.7.1.3 Для передачи структуры JWS может использоваться один из двух типов сериализации:

• компактная сериализация — представление JWS в виде компактной URL-строки,
• JSON-сериализация — представление JWS в виде объекта JSON.

При использовании компактной сериализации JWS представляется как строка:

Порядок элементов строки критичен.

В JSON-сериализации JWS представляется в виде JSON-объекта, содержащего значения следующих параметров:

• : со значением BASE64URL(UTF8()), если значение параметра не пустое; иначе значение параметра должно отсутствовать;
• : со значением ; этот параметр должен присутствовать, если значение не пустое, иначе он должен отсутствовать;
• : (обязательный) со значением BASE64URL();
• : (обязательный) со значением BASE64URL().

5.7.1.4. Имена параметров заголовка должны быть уникальными; синтаксические анализаторы JWS должны либо отклонить JWS с повторяющимися именами параметров заголовка, либо использовать анализатор JSON, который возвращает только лексически последнее повторяющееся имя элемента. Реализации настоящего стандарта должны понимать параметры , обозначенные в стандарте как «должны быть поняты», и обрабатывать их так, как определено в стандарте. Все остальные параметры , определенные в настоящем стандарте, но не обозначенные таким образом, должны игнорироваться, если они не поняты.

может включить следующие параметры:

• : (обязательный) идентификатор криптографического алгоритма цифровой подписи или MAC, используемого для защиты JWS;
• : (опциональный) URI, который указывает на ресурс, где находится ключ проверки подписи в представлении JWK (см. пункт 5.7.3), который используется для проверки цифровой подписи JWS;
• : (опциональный) ключ проверки подписи в представлении JWK (см. пункт 5.7.3), который используется для проверки цифровой подписи JWS;
• : (опциональный) идентификатор ключа, который используется для защиты JWS;
• : (опциональный) URI, который ссылается на ресурс сертификата формата X.509 или цепочки сертификатов ключа проверки цифровой подписи JWS; данный ресурс должен содержать представление сертификата или цепочки сертификатов в соответствии с RFC 5280 [32] в PEM кодировании; сертификат ключа проверки цифровой подписи JWS должен быть первым сертификатом; в цепочке сертификатов каждый последующий сертификат должен использоваться для сертификации предыдущего; получатель должен проверить цепочку сертификатов в соответствии с RFC 5280 [32], считать сертификат или цепочку сертификатов и подпись JWS недействительными в случае отрицательного результата проверки; для получения ресурса должен использоваться HTTP запрос GET и протокол TLS;
• : (опциональный) сертификат формата X.509 или цепочка сертификатов проверки цифровой подписи JWS; сертификат или цепочка сертификатов представлены в виде JSON-массива строк значений сертификата; каждая строка массива содержит кодировку Base64 (раздел 4 RFC 4648 [14], не Base64url кодирование) значение DER-представления сертификата формата X.509; сертификат ключа проверки цифровой подписи JWS должен быть первым сертификатом; в цепочке сертификатов каждый последующий сертификат должен использоваться для сертификации предыдущего; получатель должен проверить цепочку сертификатов в соответствии с RFC 5280 [32], считать сертификат или цепочку сертификатов и подпись JWS недействительными в случае отрицательного результата проверки;
• (Type): (опциональный) тип сериализации («JOSE» — компактная сериализация, «JOSE+-JSON» — JSON-сериализация);
• (Content Type): (опциональный) тип (media type) функционального содержимого JWS; как правило, используется, если в приложении несколько типов объектов могут быть представлены в качестве содержимого ;
• : (опциональный) JSON-массив имен критичных параметров заголовка; если какой-то из параметров, чье имя внесено в этот массив, не поддерживается или не понято получателем, JWS считается недействительной; если параметр присутствует, он должен быть понят и обработан получателем.

5.7.1.5. Значение цифровой подписи или MAC вычисляется с помощью алгоритма, указанного значением параметра алгоритма , используя на входе алгоритма подписи (MAC) ключ, идентифицируемый параметрами , , , , , и следующую подписываемую последовательность октетов:

Проверка подписи JWS выполняется с помощью преобразования проверки цифровой подписи. Если проверка формата JWS или проверка подписи дала отрицательный результат, JWS отвергается как не валидная.

Примечания

1 Общие сведения о структуре JWS и алгоритмах работы с ней приведены в RFC 7515 [34].

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

5.7.2. JSON-структура шифрованного текста

5.7.2.1. JWE (JSON Web Encryption) — структура данных в формате JSON, представляющая зашифрованное и защищенное от модификации сообщение.

Структура JWE:

• : JOSE заголовок — JSON-объект, содержащий параметры, описывающие криптографические операции и их параметры (см. подпункт 5.7.1.4);
• : зашифрованный ключ защиты содержимого JWE для каждого получателя;
• : синхропосылка (вектор инициализации) JWE;
• : дополнительные аутентифицируемые, не шифруемые данные JWE;
• : шифротекст JWE;
• : имитовставка JWE.

В состав входят следующие компоненты:

• : защищенный заголовок JWE, целостность значения которого будет защищаться JWE;
• : общий незащищенный заголовок JWE;
• : незащищенный заголовок для каждого получателя JWE.

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

5.7.2.2. Как и JWS, структура JWE использует компактную и JSON-сериализацию. В компактной сериализации JWE представляется следующим образом:

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

В случае JSON-сериализации JWE представлен в виде JSON-объекта, содержащего следующие параметры:

• : если заголовок не пустой, этот параметр должен присутствовать со значением BASE64URL(UTF8()); иначе этот параметр должен быть опущен;
• : если заголовок не пустой, этот параметр должен присутствовать со значением ; иначе этот параметр должен быть опущен; как правило, это JSON-объект;
• : (обязательный) массив JSON-объектов, в адрес каждого получателя JWE; структура этого объекта:
• : если заголовок не пустой, этот параметр должен присутствовать со значением ; иначе этот параметр должен быть опущен; как правило, это JSON-объект;
• <encrypted_key>: если значение не пустое, этот параметр должен присутствовать со значением BASE64URL(); иначе этот параметр должен быть опущен;
• : если значение не пустое, этот параметр должен присутствовать со значением BASE64URL(); иначе этот параметр должен быть опущен;
• : если значение не пустое, этот параметр должен присутствовать со значением BASE64URL(); иначе этот параметр должен быть опущен;
• : (обязательный) шифротекст со значением BASE64URL ();
• : если значение не пустое, этот параметр должен присутствовать со значением BASE64URL(); иначе этот параметр должен быть опущен.

5.7.2.3 Параметры JOSE заголовка:

• : (обязательный) идентификатор алгоритма шифрования, используемого для выполнения аутентифицированного шифрования открытого текста; этот параметр должен быть понят и обработан получателем;
• : (опциональный) идентификатор алгоритма сжатия, который применяется к незашифрованному тексту перед шифрованием; определено единственное значение: «DEF» — алгоритм сжатия DEFLATE; если значение этого параметра отсутствует, выполняется шифрование открытого текста без сжатия;
• , , , , , , , , : как в JWS (см. пункт 5.7.1); при этом параметры < jku>, , , , определяют открытый ключ, который был использован при формировании ключа шифрования, получатель может воспользоваться этой информацией, чтобы выбрать соответствующий закрытый ключ.

5.7.2.4 Шифрование выполняется следующим образом:

• в соответствии с идентификатором алгоритма шифрования вычислить ключ шифрования содержимого CEK;
• если используется алгоритм с шифрованием ключа, зашифровать ключ CEK, положив значением результат шифрования; если алгоритм шифрования не предполагает шифрования ключа, положить значение пустым;
• если требуется для алгоритма шифрования, сгенерировать значение случайной синхропосылки необходимой длины; иначе значение должно быть пустое;
• если указано значение параметра «zip», положить M — последовательность октетов, представляющих сжатый открытый текст; иначе M — последовательность октетов, представляющих открытый текст;
• зашифровать M с помощью алгоритма, который идентифицирован параметрами и , с использованием значений ключа CEK, синхропосылки и ; результат — шифротекст и имитовставка .

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

Примечания

1 Общие сведения о структуре JWE и алгоритмах работы с ней приведены в RFC 7516 [35].

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

5.7.3. JSON структура ключа

5.7.3.1. JSON Web Key (JWK) — это структура данных в формате JSON, представляющая криптографический ключ. Параметры этой структуры представляют свойства ключа, в том числе и значение ключа. Ниже приведена типовая структура ключа, независимо от его типа. Кроме того, в состав структуры JWK могут входить параметры, специфические для конкретных криптографических алгоритмов, использующих ключ.

5.7.3.2 В состав JWK входят следующие параметры:

• : (обязательный) тип ключа; определены следующие значения:
• «EC»: ключ для криптографического алгоритма на базе эллиптической кривой,
• «oct»: последовательность октетов, используемая для представления симметричного ключа;
• «use»: (опциональный) предполагаемое использование открытого ключа; определены следующие значения:
• «sig» — подпись,
• «enc» — шифрование;
• «key_ops»: (опциональный) идентифицирует операции, для которых предполагается использовать ключ; определены следующие значения этого параметра:
• «sign» — вычисление цифровой подписи или кода аутентификации сообщений,
• «verify» — проверка цифровой подписи или кода аутентификации сообщений,
• «encrypt» — шифрование контента,
• «decrypt» — расшифрование контента и проверка расшифрованного, если возможно,
• «wrapKey» — шифрование ключа,
• «unwrapKey» — расшифрование ключа и проверка расшифрованного, если возможно,
• «deriveKey» — вычисление производного ключа,
• «deriveBits» — вычисление производных битов не для использования в качестве ключа;
• - (опциональный) идентифицирует криптографический алгоритм, в котором предполагается использование ключа;
• - (опциональный) идентификатор ключа; используется для того, чтобы выбрать нужный ключ в документе JWK Set;
• , , , <x5t#S256>: (опциональные) как в JWS (см. пункт 5.7.1).

В зависимости от типа ключа в состав структуры JWK включаются также другие специфические параметры.

5.7.3.3. JSON-структура набора ключей JWK Set состоит из одного параметра , который является JSON-массивом ключей в формате JWK.

5.7.3.4. Документ Key Set, на который указывает значение параметра <jwks_uri> документа Discovery сервера авторизации (см. подпункт 5.4.4.1), содержит ключ(и) проверки подписи сервера авторизации. Он также может содержать открытые ключи, для которых вырабатывается общий ключ шифрования запросов к серверу авторизации. Набор Key Set, на который указывает значение параметра <jwks_uri> метаданных клиента (см. подпункт 5.4.4.5), содержит ключ(и) проверки подписи клиента. Он также может содержать открытые ключи, для которых вырабатывается общий ключ шифрования запросов к клиенту.

Если в наборе Key Set присутствуют как ключи проверки подписи, так и ключи шифрования, в структуре JWK каждого ключа должно быть указано значение параметра . Не допускается использование одного и того же ключа как для целей подписи, так и для шифрования. Параметр JWK может использоваться для предоставления ключей в формате сертификата X.509. В этом случае значение открытого ключа также должно присутствовать в составе JWK и совпадать со значением в сертификате.

Примечания

1 Общие требования к структурам JWK и JWK Set приведены в RFC 7517 [36].

2 Структуры JWK и JWK Set определяются на этапе разработки сервера авторизации и клиента.

5.7.4. Структура JSON веб-токена

5.7.4.1. JSON веб-токен (JWT) — токен доступа, основанный на формате JSON. По существу JWT — это набор параметров (claims) в формате JSON-объекта, закодированных в виде структуры JWS или JWE с цифровой подписью, кодом аутентификации и/или шифрованием.

Имена зарегистрированных параметров JWT:

• : (опциональный) идентификатор эмитента JWT (сервера авторизации, выдавшего его);
• _{: (опциональный) идентификатор субъекта JWT;}
• : (опциональный) перечень идентификаторов получателей, которым предназначен JWT;
• : (опциональный) время завершения срока действия JWT в секундах;
• : (опциональный) время, до которого JWT не должен приниматься к обработке;
• : (опциональный) время выпуска JWT;
• : (опциональный) идентификатор JWT.

Эти параметры JWT помещаются в компоненте JWS Payload или в зашифрованном виде — в содержимое JWE Ciphertext.

5.7.4.2. JWT может быть либо подписан, либо подписан и зашифрован. Если JWT подписан и зашифрован, JSON-документ будет подписан, затем зашифрован, а результатом будет структура вложенного JWT — Nested JWT.

5.7.4.3. В JOSE-заголовке JWT независимо от типа (JWS или JWE) используются два параметра: (рекомендуется использовать строку «JWT») и  (при наличии вложенной подписи или шифрования его значением должна быть строка «JWT»).

Примечание. Дополнительные сведения по структурам JWT и Nested JWT приведены в RFC 7519 [12].

5.8. МЕХАНИЗМЫ ЗАЩИТЫ

5.8.1. Цифровая подпись и шифрование

5.8.1.1. В зависимости от транспорта, с помощью которого отправляются сообщения, целостность сообщения может не гарантироваться, а отправитель сообщения может не проходить проверку подлинности. Чтобы уменьшить эти риски, при обработке значений ID токена, ответа UserInfo, объекта запроса и аутентификации клиента может использоваться JWS для цифровой подписи содержимого этих структур данных. Для обеспечения конфиденциальности сообщений также может использоваться JWE для шифрования содержимого этих структур данных.

Сервер авторизации может объявлять о поддерживаемых им алгоритмах подписи и шифрования в своем документе Discovery (см. подпункт 5.4.4.1) или предоставлять эту информацию другими способами. Клиент может декларировать свои алгоритмы цифровой подписи и шифрования в своем запросе динамической регистрации (см. подпункт 5.4.4.5) или передавать эту информацию другими способами.

Сервер авторизации может объявлять свои открытые ключи цифровой подписи и шифрования через документ Discovery или предоставлять эту информацию другими способами. Клиент может объявлять свои открытые ключи через запрос динамической регистрации или передавать эту информацию другими способами.

5.8.1.2 Цифровая подпись

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

Ключ асимметричной цифровой подписи

Ключ цифровой подписи, который используется для формирования подписи контента, должен быть связан с открытым ключом, используемым для проверки цифровой подписи и опубликованным отправителем в его документе JWK Set. Если в указанном документе JWK Set есть несколько ключей, в JOSE-заголовке должно присутствовать значение параметра . Параметр соответствующего ключа должен указывать на то, что этот ключ поддерживает алгоритм цифровой подписи («sig»).

Ключ кода аутентификации сообщения

При использовании подписи JWS на основе кода аутентификации сообщения (MAC) значение параметра JOSE заголовка должно быть равно идентификатору алгоритма MAC. Используемый ключ MAC — это октеты UTF-8 представления значения <client_secret>. Требования к энтропии значений <client_secret> см. в пункте 5.8.2. Симметричная подпись не должна использоваться публичными клиентами из-за их неспособности сохранять ключ клиента.

5.8.1.3 Смена асимметричных ключей подписи

Смена асимметричных ключей цифровой подписи может быть выполнена с помощью следующего подхода. Подписывающий публикует свои ключи в документе JWK Set, местоположение которого указывает в качестве значения параметра <jwks_uri> документа Discovery (см. подпункт 5.4.4.1), и включает идентификатор ключа цифровой подписи в качестве значения параметра JOSE-заголовка каждого JWS сообщения, чтобы указать проверяющему, какой ключ должен использоваться для проверки цифровой подписи. Ключи можно обновлять, периодически добавляя новые ключи проверки цифровой подписи в JWK Set по адресу <jwks_uri>. Подписывающий может начать использовать новый ключ цифровой подписи по своему усмотрению, сигнализируя об этом проверяющему, использовав новое значение параметра . Проверяющий понимает, что, обнаружив незнакомое значение параметра , он должен обратиться по адресу <jwks_uri> для повторного получения ключей отправителя. Документ JWK Set по адресу <jwks_uri> должен сохранять недавно выведенные из действия ключи проверки цифровой подписи в течение периода времени, соответствующего требованиям к СКЗИ.

5.8.1.4 Шифрование

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

Асимметричное шифрование на основе арифметики эллиптической кривой

Генерируется эфемерный открытый ключ с использованием арифметики эллиптической кривой в качестве элемента JOSE-заголовка JWE. Второй открытый ключ, используемый для ключевого соглашения (key agreement), должен быть открытым ключом, опубликованным получателем в его документе JWK Set. Если в указанном документе JWK Set есть несколько ключей, в JOSE-заголовке JWE должно быть указано значение параметра . Для согласования ключа шифрования контента, который будет использован для шифрования подписанного JWT, следует использовать алгоритм ключевого соглашения с использованием арифметики эллиптической кривой. Параметр соответствующего ключа должен включать шифрование («enc»).

Симметричное шифрование

Симметричный ключ шифрования вычисляется из значения <client_secret> с использованием усеченного слева хэш-кода октетов UTF-8 представления параметра <client_secret>. Симметричное шифрование не должно использоваться публичными клиентами из-за их неспособности сохранять ключ клиента.

5.8.1.5 Смена асимметричных ключей шифрования

При смене ключей шифрования следует использовать процесс, отличный от процесса смены ключей цифровой подписи, поскольку процесс смены открытого ключа получателя запускает получатель, не являющийся отправителем (шифрующим), и, таким образом, отправитель не может полагаться на изменение параметра в качестве сигнала о необходимости смены ключей. Шифрующий продолжает использовать прежний параметр в заголовке JWE. При этом он должен выбрать наиболее подходящий ключ из представленных в JWK Set, расположенном по адресу <jwks_uri> получателя. При отсутствии в JWK Set открытого ключа получателя с разрешенным сроком использования шифрование не допускается. Об этом следует сообщить получателю, пользуясь другим надежным каналом связи.

Для смены ключей расшифровывающая сторона своевременно должна опубликовать новые ключи по своему адресу <jwks_uri> и удалить из JWK Set те ключи, которые выводятся из эксплуатации. Должны быть приняты меры по корректному кэшированию <jwks_uri> в соответствии с рекомендациями пункта 10.2.1 [11]. Получатель должен удалить отозванные ключи из JWK Set, но сохранять их у себя в течение некоторого периода времени, согласованного с продолжительностью кэша, чтобы обеспечить плавный переход между ключами, предоставляя отправителю некоторое время на загрузку новых ключей. Продолжительность кэша следует также координировать с выдачей новых ключей подписи, как описано в подпункте 5.8.1.3.

5.8.2. Требования к энтропии симметричных ключей

Ключи формирования MAC JWS и симметричного шифрования JWE вычисляются на основе значения ключа клиента <client_secret> (см. подпункт 5.4.4.5). Таким образом, при использовании с симметричными операциями подписи (MAC) или шифрования значения <client_secret> должны содержать достаточную энтропию для генерации криптографически стойких ключей.

Значения ключа клиента <client_secret> и другая ключевая информация должны генерироваться с помощью СКЗИ, используемого при реализации криптографической защиты информации ФАПИ.СЕК.

Кроме того, длина значения <client_secret> должна быть не менее той, которая требуется для ключей MAC для конкретного используемого алгоритма. При использовании кода аутентификации HMAC с длиной значения 256 битов значение <client_secret> должно быть не менее 256 битов. При использовании кода аутентификации HMAC с длиной значения 512 битов значение <client_secret> должно быть не менее 512 битов.

5.8.3. Требования к TLS

5.8.3.1. Приложения, соответствующие настоящему стандарту, должны выполнять следующие требования к использованию протокола TLS.

Реализация протокола TLS с использованием криптографических алгоритмов Российской Федерации должна выполняться в соответствии с положениями рекомендаций по стандартизации Р 1323565.1.020. Допускается использование сертифицированных федеральным органом исполнительной власти в области обеспечения безопасности СКЗИ, реализующих TLS в соответствии с требованиями МР 26.2.001-2013 [37], до окончания срока действия сертификата на использование СКЗИ.

5.8.3.2. Все взаимодействия между клиентом и сервером авторизации, между клиентом и сервером ресурсов, между сервером авторизации и сервером ресурсов должны быть защищены с использованием TLS (HTTPS). Данное требование относится к взаимодействиям в рамках всех указанных в стандарте протоколов (регистрация клиентов, взаимодействие по протоколам OIDC), ко всем сценариям (с кодом авторизации и гибридный), ко всем режимам доступа к защищаемому ресурсу (только чтение и чтение/запись).

5.8.3.3. Для всех коммуникаций должен использоваться TLS версии 1.2 или более поздней.

5.8.3.4 Должна осуществляться проверка сертификата TLS-сервера.

5.8.3.5. Криптографические ключи, используемые в протоколе TLS, и ключи протокола OIDC должны быть различными.

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

• TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC (Р 1323565.1.020),
• TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC (Р 1323565.1.020),
• TLS_GOSTR341112_256_WITH_28147_CNT_IMIT [37].

5.8.3.7. Сервер авторизации, сервер ресурсов не должны быть доступны без использования TLS. В случае обращения клиента без использования TLS сервер авторизации, сервер ресурсов должны отказать в соединении или возвратить сообщение со статусом HTTP 301 и кодом ошибки «Moved Permanently».

5.8.4. Токен доступа, связанный с MTLS-сертификатом клиента

5.8.4.1. Если клиент использует взаимную аутентификацию по протоколу TLS при подключении к конечной точке токена, сервер авторизации может связать выданный токен доступа с предъявленным сертификатом клиента. Такое связывание достигается путем встраивания хэш-кода сертификата в выданный токен доступа с использованием JWT-синтаксиса (см. подпункт 5.8.4.2) или посредством интроспекции токена (запроса информации о токене) у сервера авторизации (см. подпункт 5.8.4.3). Эта привязка может выполняться как совместно с аутентификацией клиента по сертификату MTLS (см. пункты 5.5.4 и 5.5.5), так и отдельно от аутентификации клиента сервером авторизации, что позволяет MTLS во время защищенного доступа к ресурсам служить исключительно механизмом подтверждения владения закрытым ключом.

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

В процессе доступа к ресурсам, защищенным протоколом TLS с взаимной аутентификацией сторон, клиент может выполнять запросы к защищенным ресурсам, как описано в подразделе 5.6, однако эти запросы должны быть выполнены по аутентифицированному MTLS-соединению, используя тот же сертификат, который использовался для MTLS-соединения в конечной точке токена при запросе токена доступа.

Сервер ресурсов должен получить TLS-сертификат клиента, используемый для установления взаимно аутентифицированного TLS-соединения, должен проверить, что сертификат соответствует сертификату, связанному с предъявленным токеном доступа. Если они не совпадают, попытка доступа к ресурсу должна быть отклонена со статусом HTTP 401 и кодом ошибки «invalid_token».

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

5.8.4.2 Метод подтверждения отпечатка сертификата с использованием JWT

Чтобы представить хэш-код Х.509 сертификата в формате JWT (5.7), в качестве значения параметра токена используется строка, идентифицирующая метод подтверждения на основе хэш-функции с длиной образа не менее 256 битов, и значение хэш-кода, которое формируется как Base64url кодирование значения хэш-функции, вычисленное от DER-представления (по ГОСТ Р ИСО/МЭК 8825-1) сертификата формата Х.509.

Примечание. Дополнительные сведения о методе подтверждения отпечатка сертификата с использованием JWT приведены в [39] (подраздел 3.1).

Ниже приведен пример функционального содержимого JWT, содержащего подтверждение отпечатка сертификата.

5.8.4.3 Метод подтверждения отпечатка сертификата с использованием интроспекции токена

Интроспекция токена OAuth 2.0 определяет способ, с помощью которого сервер ресурсов может запрашивать у сервера авторизации информацию о состоянии активности токена доступа, а также другую метаинформацию о токене доступа.

Для токена доступа, связанного с сертификатом MTLS, хэш-код сертификата, с которым связан токен, передается серверу защищенного ресурса в виде метаинформации в составе ответа интроспекции токена. Хэш-код передается с использованием того же параметра с элементом, идентифицирующим метод подтверждения на основе хэш-функции, что и при использовании метода подтверждения отпечатка сертификата, описанного в подпункте 5.8.4.2, в качестве параметра верхнего уровня JSON-ответа интроспекции. Сервер ресурсов сравнивает полученный таким образом хэш-код сертификата со значением хэш-кода, вычисленного на основе сертификата клиента, использованного для взаимной аутентификации сеанса TLS, и отклоняет запрос, если они не совпадают.

Примечания

1 Дополнительные сведения о протоколе интроспекции токена доступа представлены в RFC 7662 [38].

2 Дополнительные сведения о методе подтверждения отпечатка сертификата с использованием интроспекции токена приведены в [39] (подраздел 3.1).

Ниже приведен пример ответа интроспекции для активного токена с подтверждением отпечатка сертификата.

5.8.4.4 Метаданные сервера авторизации и клиента для подтверждения отпечатка MTLS-сертификата

Следующий параметр метаданных сервера авторизации, публикуемый в соответствии с требованиями подпункта 5.4.4.1, указывает на способность сервера авторизации выдавать токены доступа с привязкой к сертификату:

• <tls_client_certificate_bound_access_tokens>: (опциональный) логическое значение, указывающее на поддержку сервером токенов доступа с привязкой к MTLS-сертификату клиента. Значением по умолчанию является «false».

Следующий параметр метаданных клиента, публикуемый в соответствии с требованиями подпункта 5.4.4.5, позволяет сигнализировать о намерении клиента использовать токены доступа с привязкой к сертификату:

• <tls_client_certificate_bound_access_tokens>: (опциональный) логическое значение, используемое для указания намерения клиента использовать токены доступа, привязанные к MTLS-сертификату клиента. Значением по умолчанию является «false».

Если клиент, который указал намерение использовать токены, привязанные к MTLS-сертификату клиента, отправляет запрос на конечную точку токена по соединению, не являющемуся MTLS, на усмотрение сервера авторизации остается принятие решения относительно того, следует ли возвращать ошибку или выдать токен, не связанный с сертификатом.

6. ПРОФИЛЬ БЕЗОПАСНОСТИ OPENID API ДЛЯ ДОСТУПА К СЕРВИСАМ В РЕЖИМЕ ТОЛЬКО ДЛЯ ЧТЕНИЯ

6.1. ВВОДНАЯ ИНФОРМАЦИЯ

Раздел 6 определяет требования по использованию OIDC, обеспечивающие приложению:

• получение токенов доступа и в некоторых случаях токенов обновления OAuth для доступа к защищенным данным только для чтения;
• использование OIDC для идентификации клиента (пользователя);
• использование токенов для чтения защищенных данных с конечных точек REST.

В разделе приведены спецификации ФАПИ.СЕК, которые являются реализацией REST-стиля построения API с использованием форматов JSON. Эти API защищены технологиями авторизации OAuth 2.0 (см. подраздел 5.3) и OpenID Connect (см. подраздел 5.4).

6.2. ПОЛОЖЕНИЯ ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ АВТОРИЗАЦИИ

6.2.1. В связи с тем, что на основании стандарта ФАПИ.СЕК может предоставляться потенциально чувствительная информация, она требует более высокого уровня защиты, чем базовые требования OAuth 2.0.

6.2.2 Сервер авторизации:

1 должен поддерживать конфиденциальных клиентов;

2 не должен поддерживать доступ в режиме чтения со стороны публичных клиентов;

3 в случае использования симметричного ключа должен предоставлять ключ клиента <client_secret», соответствующий требованиям пункта 5.8.2;

4 должен аутентифицировать конфиденциального клиента в конечной точке токена, используя один из следующих методов:

• TLS с взаимной аутентификацией сторон взаимодействия протокола OAuth 2.0 и его профилей, включая OIDC, как определено в пунктах 5.5.4 или 5.5.5;

<client_secret_JWT> или <private_key_JWT>, как определено в пунктах 5.5.2 и 5.5.3;

5 должен требовать ключ, размер которого составляет 256 бит или больше, если для аутентификации клиента используются алгоритмы, основанные на использовании эллиптической кривой;

6 должен требовать предварительной регистрации URI переадресации клиента;

7 должен требовать наличия параметра <redirect_URI> в запросе аутентификации (см. подпункт 5.4.2.2);

8 должен требовать, чтобы значение параметра <redirect_URI> точно соответствовало одному из предварительно зарегистрированных URI переадресации клиента (см. подпункт 5.4.4.5);

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

10 должен исключать повторное использование кодов авторизации в соответствии с рекомендациями подпункта 5.4.2.13;

11 должен возвращать ответ с токеном доступа и, если это установлено при разработке сервера авторизации, с токеном обновления в соответствии с подпунктом 5.4.2.10;

12 должен возвращать список предоставленных областей действия (параметр ) по выданному токену доступа (см. подпункт 5.4.2.20);

13 должен предоставлять непредсказуемые значения токенов доступа как минимум с 128-битной энтропией; при этом рекомендуется генерировать токены с энтропией не ниже 160 бит;

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

14 рекомендуется уведомлять владельца ресурса о том, что клиент запрашивает долгосрочное разрешение на доступ (см. подпункт 5.4.2.19);

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

16 при обращении к методам аутентификации клиента, которые могут передавать идентификатор клиента более чем одним разрешенным способом, в случае предоставления несовпадающих идентификаторов клиента должен возвращать код ошибки «invalid_client»;

17 должен требовать, чтобы сервисы по адресу URI переадресации использовали протокол HTTPS.

6.2.3. При предоставлении клиенту в ответе на запрос токена доступа идентификатор аутентифицированного пользователя сервер авторизации:

1 должен поддерживать запрос аутентификации в соответствии с подпунктом 5.4.2.2;

2 должен осуществлять проверку запроса аутентификации в соответствии с подпунктом 5.4.2.5;

3 должен предоставлять ответ на запрос аутентификации в соответствии с подпунктами 5.4.2.7 и 5.4.2.8 в зависимости от результата аутентификации;

4 должен осуществлять проверку запроса токена в соответствии с подпунктом 5.4.2.12;

5 если параметр запроса аутентификации включает «openid», должен генерировать ID токен в составе ответа на запрос токена в соответствии с подпунктом 5.4.2.14; при этом значение параметра _{должно соответствовать аутентифицированному пользователю.}

6.2.4 Клиент:

1 может использовать механизмы, определенные в разделе 7;

2 должен использовать разные URI переадресации для каждого сервера авторизации, на котором зарегистрирован клиент;

3 должен поддерживать следующие методы аутентификации в конечной точке токена:

• TLS с взаимной аутентификацией клиента OAuth, как определено в пунктах 5.5.4 и 5.5.5;
• <client_secret_JWT> или <private_key_JWT>, как определено в пунктах 5.5.2 и 5.5.3;

4 должен использовать ключи криптографии с эллиптической кривой с минимальным размером 256 бит, если используются криптографические алгоритмы на основе арифметики эллиптической кривой;

5 должен проверять, что значение ключа клиента <client_secret> имеет длину не менее 256 бит, если используется криптография с симметричным ключом.

Если по результатам аутентификации клиент запрашивает получение постоянного идентификатора аутентифицированного клиента, клиент:

6 должен включать строку «openid» в перечень значений параметра ;

7 должен включать параметр (см. подпункт 5.4.2.2) в состав запроса аутентификации.

Если строка «openid» не включена в перечень значений параметра , конфиденциальный клиент:

8 должен включать параметр (см. подпункт 5.4.2.2).

6.3. ТРЕБОВАНИЯ К ДОСТУПУ К ЗАЩИЩЕННЫМ РЕСУРСАМ ТОЛЬКО ДЛЯ ЧТЕНИЯ

6.3.1. Конечные точки ресурсов возвращают клиенту защищенную информацию владельца ресурса, связанного с предъявленным токеном доступа.

6.3.2 Сервер ресурсов, предоставляющий доступ к данным в соответствии с настоящим стандартом:

1 должен поддерживать метод HTTP GET;

2 должен принимать токены доступа в HTTP заголовке в соответствии с пунктом 5.6.2;

3 не должен принимать токены доступа в параметрах запроса;

4 должен проверять, что срок действия токена доступа не истек и токен доступа не отозван;

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

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

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

8 должен кодировать ответ в UTF-8;

9 должен отправлять параметр HTTP заголовка в виде «Content-Type: application/JSON; charset = UTF-8»;

10 должен отправлять текущую дату на сервере в HTTP заголовке даты;

11 должен устанавливать в качестве значения заголовка ответа либо значение, полученное из соответствующего заголовка запроса клиента, либо значение UUID, если заголовок запроса не предоставлялся для отслеживания взаимодействия, например, «x-FAPI-interaction-id: c770aef3-6784-41f7-8e0e-ff5f97bddb3a»;

12 должен регистрировать значение в записи журнала регистрации.

Примечания

1 Форматы и алгоритмы формирования UUID определены в RFC 4122 [40].

2 Для получения информации об объекте, связанном с токеном доступа и предоставленной областью действия, сервер ресурсов может использовать протокол интроспекции токена, описанный в RFC 7662 [38].

6.3.3 Клиент, реализующий доступ к защищенному ресурсу в соответствии с требованиями данного стандарта:

1 должен отправлять токены доступа в заголовке HTTP в соответствии с пунктом 5.6.2;

2 может отправлять последнюю дату регистрации пользователя в клиенте в заголовке , причем значение предоставляется в формате HTTP даты; например, «x-FAPI-auth-date: Tue, 11 Sep 2012 19:43:31 GMT»;

3 может отправлять в заголовке IP-адрес пользователя, если эти данные ему доступны; например, «x-FAPI-customer-ip-address: 198.51.100.119»;

4 для синхронизации записей журналов регистрации клиента и сервера ресурсов может отправлять серверу заголовок запроса, значением которого является UUID; например, «x-FAPI-interaction-id: c770aef3-6784-41f7-8e0e-ff5f97bddb3a».

7. ПРОФИЛЬ БЕЗОПАСНОСТИ OPENID API ДЛЯ ДОСТУПА К СЕРВИСАМ В РЕЖИМЕ ЧТЕНИЯ И ЗАПИСИ

7.1. ВВОДНАЯ ИНФОРМАЦИЯ

7.1.1 В данном разделе определяются требования к тому:

• как приложение может получить токен OAuth для доступа к данным с повышенным уровнем риска,
• как приложение может использовать OpenID Connect для идентификации пользователей;
• как использовать токены для взаимодействия с конечными точками REST, предоставляющими защищенные данные.

В данном разделе определены спецификации ФАПИ.СЕК, являющиеся интерфейсами REST API. В этих спецификациях предоставлены JSON-структуры для форматов данных с повышенным риском. Эти программные интерфейсы защищены протоколами авторизации OAuth 2.0 (см. подраздел 5.3) и OpenID Connect (см. подраздел 5.4).

В рамках настоящего протокола также допустимо включение в качестве одного из параметров ID токена временного идентификатора субъекта — владельца ресурса. В этом случае ID токен выполняет функции отдельной подписи (detached signature) ответа на запрос авторизации.

В данном разделе ответ на запрос авторизации защищается путем включения хэш-значений всех незащищенных параметров ответа, например и .