5. ОБЩИЕ ПОЛОЖЕНИЯ

5. ОБЩИЕ ПОЛОЖЕНИЯ

5.1. СТРУКТУРА СТАНДАРТА

5.1.1. Настоящий стандарт (далее - ФАПИ.СЕК) предоставляет требования и рекомендации для обеспечения безопасного доступа к финансовым данным в финансовых сервисах реального времени с использованием модели обмена данными REST/JSON, защищенной технологией OAuth, включая профилирующий ее протокол OpenID Connect.

ФАПИ.СЕК состоит из следующих частей:

- профиль безопасности OpenID API для доступа к сервисам в режиме только для чтения;

- профиль безопасности OpenID API для доступа к сервисам в режиме чтения и записи;

- защищенный с использованием JWT режим ответа на запрос авторизации OAuth 2.0 (JARM).

В разделе 5 настоящего стандарта приведены нормативные требования (см. подраздел 5.2), а также общие сведения о протоколах авторизации OAuth 2.0 и аутентификации OpenID Connect (см. подразделы 5.3 - 5.8).

Первая часть ФАПИ.СЕК (раздел 6) основана на документе [15], выпущенном OpenID Foundation. В этой части определяются требования к системным (безопасность на уровне транспорта и алгоритмов преобразования данных) и прикладным параметрам протокола OpenID Connect, выполнение которых является обязательным для обеспечения безопасного доступа к конфиденциальной финансовой информации/данным в режиме только для чтения.

Вторая часть (раздел 7), источник [16], представляет профиль безопасности более высокого уровня - профиль API для чтения и записи финансовых данных и других аналогичных ситуаций с повышенным риском несанкционированной модификации данных. В ней определяются меры защиты от таких атак, как фальсификация запроса авторизации, фальсификация ответа на запрос авторизации, включая внедрение кода, внедрение состояния и фишинг запроса токена.

Третья часть настоящего стандарта - JARM (раздел 8) - основана на документе [17] и определяет использующий токены доступа JWT-формат представления ответов на запросы авторизации. Клиентам дается возможность запрашивать передачу параметров ответа на запрос авторизации вместе с дополнительными данными в JWT-формате. Этот механизм повышает безопасность стандартного ответа на запрос авторизации, поскольку добавлены поддержка подписи и шифрования, аутентификация отправителя, ограничение аудитории, а также защита от повторного воспроизведения, утечки учетных данных и атак путем подмены/перепутывания. Он может быть объединен с любым типом ответа.

5.2. НОРМАТИВНЫЕ ТРЕБОВАНИЯ

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

- Федеральным законом от 27 июля 2006 года N 152-ФЗ "О персональных данных" [18];

- постановлением Правительства Российской Федерации от 1 ноября 2012 г. N 1119 "Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных" [19];

- приказом Федеральной службы безопасности (ФСБ России) от 10 июля 2014 г. N 378 "Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности" [20];

- приказом Федеральной службы по техническому и экспортному контролю (ФСТЭК России) от 18 февраля 2013 г. N 21 "Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных" [21].

5.2.2. Прикладное программное обеспечение, реализующее требования настоящего стандарта, должно отвечать требованиям Положений Банка России от 9 июня 2012 года N 382-П [22], от 17 апреля 2019 года N 683-П [23], от 17 апреля 2019 года N 684-П [24] в части, предъявляемой к анализу уязвимостей в прикладном ПО как на этапе его разработки, так и при его использовании в составе конечных целевых систем.

Разработка программного обеспечения, реализующего требования настоящего стандарта, должна вестись в соответствии с ГОСТ Р 56939. В том числе должен проводиться регулярный поиск информации, связанной с уязвимостями программ, в общедоступных источниках, в том числе с использованием банка данных угроз безопасности информации ФСТЭК России.

5.2.3. Оценка соответствия и сертификация реализаций, отвечающих требованиям настоящего стандарта, производится в соответствии с законодательством Российской Федерации.

5.3. ТЕХНОЛОГИЯ АВТОРИЗАЦИИ OAUTH 2.0

5.3.1. OAuth 2.0 - семейство протоколов авторизации, позволяющих одному приложению - клиенту - получить доступ к данным другого приложения - сервера ресурсов. При этом клиент получает разрешение на доступ от имени пользователя - владельца ресурса, который владеет необходимыми учетными данными, позволяющими его аутентифицировать. Непосредственно разрешение на доступ (grant) выдает клиенту сервер авторизации, на котором зарегистрирован владелец ресурса. Сервер ресурсов и сервер авторизации могут совпадать.

Примечание. Сведения о спецификации OAuth 2.0 приведены в документах RFC 6749 [10] и RFC 6750 [13].

5.3.2. Схематично сценарий протокола OAuth 2.0 представлен на рисунке 1. Он описывает взаимодействие между упомянутыми выше четырьмя сторонами и включает следующие шаги.

1 Клиент запрашивает авторизацию у владельца ресурса. Запрос авторизации может быть направлен владельцу ресурса напрямую, как показано на рисунке 1, или косвенно через сервер авторизации. Предпочтительным является второй вариант.

2 Клиент получает разрешение на доступ (grant), структуру данных, представляющую авторизацию владельца ресурса, выраженную с использованием одного из четырех типов разрешений: код авторизации (authorization code), неявное разрешение (implicit), пароль владельца ресурса (resource owner password credentials) и учетные данные клиента (client credentials). Тип разрешения на доступ зависит от метода, используемого клиентом для запроса авторизации, и типов разрешений, поддерживаемых сервером авторизации. Типы разрешений, поддерживаемые сервером авторизации, определяются при его разработке, исходя из его прикладных целей и задач. Настоящий стандарт регламентирует использование в качестве типа разрешения код авторизации.

3 Клиент запрашивает токен доступа посредством аутентификации на сервере авторизации и предоставления разрешения на доступ.

4 Сервер авторизации аутентифицирует клиента, проверяет разрешение на доступ и, если оно действительно, выдает токен доступа.

5 Клиент запрашивает защищенный ресурс на сервере ресурсов и аутентифицируется, представляя токен доступа.

6 Сервер ресурсов проверяет токен доступа и, если он действителен, обслуживает запрос.

СЦЕНАРИЙ ПРОТОКОЛА OAUTH 2.0
Рис. 1

Рисунок (не приводится)

5.3.3. Для связи сервер авторизации и клиент используют конечные точки - адреса ресурсов или точки входа соответствующих сервисов. В процессе авторизации OAuth 2.0 используются две конечные точки сервера авторизации - конечная точка авторизации и конечная точка токена, а также одна конечная точка клиента.

5.3.4. Сервер авторизации должен поддерживать использование метода HTTP GET на конечной точке авторизации и может также поддерживать использование метода POST. При осуществлении запросов токена доступа клиент должен использовать метод HTTP POST.

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

5.4. OPENID CONNECT

5.4.1. Протокол OpenID Connect

5.4.1.1. OIDC - семейство протоколов, являющихся расширением протоколов OAuth 2.0, позволяющих расширить их функционал путем более точного описания процесса аутентификации владельца ресурса и возможности клиенту получить информацию о нем. Это этапы (1) - (4) протокола OAuth 2.0 (см. рисунок 1).

5.4.1.2. Схематично протокол OpenID Connect выглядит следующим образом (см. рисунок 2):

1 Клиент отправляет серверу авторизации запрос аутентификации.

2 Сервер авторизации аутентифицирует конечного пользователя и получает согласие пользователя на доступ клиента к запрошенному ресурсу.

3 Сервер авторизации отвечает клиенту ID токеном и (опционально) токеном доступа.

4 Клиент может отправить серверу авторизации запрос информации о пользователе по токену доступа.

5 Сервер авторизации возвращает клиенту информацию о конечном пользователе.

СЦЕНАРИЙ АУТЕНТИФИКАЦИИ OPENID CONNECT
Рис. 2

Рисунок (не приводится)

5.4.1.3. Сервер авторизации OpenID Connect поддерживает три сценария аутентификации, реализующие этот сценарий: с генерацией кода авторизации (Authorization Code Flow), неявный сценарий (Implicit Flow), гибридный сценарий (Hybrid Flow). Настоящий стандарт не предполагает использование неявного сценария.

5.4.1.4. Передача сообщений между клиентом и сервером авторизации (на конечных точках авторизации, токена и UserInfo) должна производиться с использованием протокола TLS.

Примечание. Дополнительные сведения об OIDC приведены в документе [11].

5.4.2. Аутентификация с генерацией кода авторизации

5.4.2.1. Сценарий протокола аутентификации OpenID Connect с генерацией кода авторизации использует код авторизации в качестве типа разрешения на доступ (grant). При этом выполняются следующие действия:

1 Клиент генерирует запрос аутентификации.

2 Клиент, используя агент пользователя (User Agent), отправляет запрос аутентификации на конечную точку авторизации сервера авторизации.

3 Сервер авторизации аутентифицирует конечного пользователя.

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

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

6 Клиент запрашивает ID токен и токен доступа, используя код авторизации на конечной точке токена.

7 Клиент получает ответ, содержащий ID токен и токен доступа.

8 Клиент проверяет ID токен (см. подпункт 5.4.2.17) и получает идентификатор конечного пользователя.

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

- <scope>: (обязательный) область действия; определяет свойства защищаемых данных конечного пользователя, к которым запрошен доступ; в случае использования протокола OpenID Connect параметр <scope> должен содержать строку "openid";

- <response_type>: (обязательный) тип ответа и сценарий протокола авторизации; в данном сценарии используется следующее значение:

- "code": возвращает код авторизации; используется в сценарии аутентификации с генерацией кода авторизации;

- <client_id>: (обязательный) идентификатор клиента OAuth2.0, полученный при регистрации на сервере авторизации (см. подпункт 5.4.4.5);

- <redirect_uri>: (обязательный) URI переадресации, на который будет отправлен ответ; должен быть предварительно зарегистрирован на сервере авторизации (см. подпункт 5.4.4.5);

- <state>: (рекомендуемый) значение, используемое для синхронизации состояния между запросом и обратным вызовом; используется для защиты от атак межсайтовых запросов (CSRF);

- <nonce>: (опциональный) случайное строковое значение, используемое для привязки сеанса клиента к ID токену и для защиты от атак повторного воспроизведения;

- <prompt>: (опциональный) список строк, которые указывают, должен ли сервер авторизации запрашивать у конечного пользователя повторную аутентификацию и согласие на доступ клиента к ресурсу. Определены значения:

- "none" - не требуется интерфейс пользователя,

- "login" - серверу авторизации рекомендуется запросить повторную аутентификацию,

- "consent" - серверу авторизации рекомендуется запросить у пользователя согласие на доступ к ресурсу,

- "select_account" - серверу авторизации рекомендуется запросить у пользователя выбор учетной записи;

- <max_age>: (опциональный) максимальный срок аутентификации. Определяет допустимое время в секундах, прошедшее с момента последней активной аутентификации конечного пользователя сервером авторизации. Если истекшее время больше этого значения, сервер авторизации должен пытаться активно повторно аутентифицировать конечного пользователя. Если в запросе аутентификации присутствует параметр <max_age>, возвращаемый ID токен должен включать значение параметра <auth_time>.

Примечание. Дополнительные сведения по параметрам запроса аутентификации приведены в RFC 6749 [10] (пункт 4.1.1) и в OIDC [11] (подпункт 3.1.2.1).

5.4.2.3. Серверы авторизации должны поддерживать на конечной точке авторизации методы HTTP GET и POST. Клиенты могут использовать методы HTTP GET или POST для отправки запроса аутентификации на сервер авторизации. При использовании метода HTTP GET параметры запроса сериализуются с использованием URI Query String Serialization (см. [11], подраздел 13.1). При использовании метода HTTP POST параметры запроса сериализуются с использованием сериализации форм (Form Serialization) (см. [11], подраздел 13.2).

5.4.2.4. Также параметры запроса аутентификации могут быть переданы в качестве параметров (claims) JSON объекта запроса - JWT токена. JWT токен должен быть подписан и может быть зашифрован. JWT токен передается в кодировании Base64url (см. [14], раздел 5) по значению через параметр <request> или по ссылке через параметр <request_uri>.

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

5.4.2.5. Сервер авторизации должен проверить полученный запрос следующим образом:

1 Проверить наличие обязательных параметров запроса и их соответствие спецификациям OAuth 2.0 и OIDC.

2 Убедиться, что параметр <scope> содержит значение области действия "openid".

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

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

5.4.2.6. Если запрос аутентификации действителен, сервер авторизации пытается аутентифицировать конечного пользователя или определяет, аутентифицирован ли конечный пользователь. Методы, используемые сервером авторизации для аутентификации конечного пользователя (например, имя пользователя и пароль, файлы cookie сеанса и т.д.), не регламентируются настоящим стандартом.

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

- конечный пользователь еще не аутентифицирован;

- запрос аутентификации содержит параметр <prompt> со значением "login". В этом случае сервер авторизации должен повторно аутентифицировать конечного пользователя, даже если конечный пользователь уже аутентифицирован.

Сервер авторизации не должен взаимодействовать с конечным пользователем в следующем случае: запрос аутентификации содержит параметр <prompt> со значением "none". В этом случае сервер авторизации должен возвратить ошибку, если конечный пользователь еще не прошел аутентификацию или не может быть аутентифицирован в режиме без вывода сообщений.

При взаимодействии с конечным пользователем сервер авторизации должен использовать соответствующие меры против подделки межсайтовых запросов (CSRF) и перехвата кликов (Clickjacking).

5.4.2.7. После аутентификации конечного пользователя сервер авторизации должен получить его разрешение об авторизации доступа к запрошенному ресурсу, прежде чем предоставлять информацию клиента. В случае если это определено параметрами запроса, разрешение может быть получено одним из следующих способов:

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

- путем установления согласия с помощью условий обработки запроса;

- другими способами (например, с помощью предыдущего административного согласования).

5.4.2.8. После успешной аутентификации конечного пользователя и получения его разрешения на доступ клиента к защищенному ресурсу сервер авторизации генерирует код авторизации и передает его на конечную точку клиента, воспользовавшись адресом, который был ранее указан в параметре <redirect_uri> запроса аутентификации, с использованием формата "application/x-www-form-urlencoded". Параметры успешного ответа на запрос аутентификации:

- <code>: (обязательный) значение кода авторизации; размер строки кода авторизации должен определяться при проектировании сервера авторизации;

- <state>: (обязательный, если параметр <state> присутствует в запросе аутентификации) значение параметра <state> запроса аутентификации, полученного от клиента.

5.4.2.9. В случае ошибки при проверке запроса аутентификации либо в процессе аутентификации конечного пользователя сервер авторизации отвечает клиенту с указанием информации об ошибке.

Параметры сообщения об ошибке:

- <error>: (обязательный) код ошибки;

- <error_description>: (опциональный) текстовое описание ошибки;

- <error_uri>: (опциональный) URI веб-страницы с дополнительной информацией об ошибке;

- <state>: (обязательный, если параметр <state> присутствует в запросе аутентификации) значение параметра <state> запроса аутентификации, полученного от клиента.

Возможные значения кода ошибки:

- "invalid_request": в запросе отсутствует обязательный параметр, или он содержит недопустимое значение параметра, или содержит параметр более одного раза, или имеет иные неправильные значения параметров;

- "unauthorized_client": клиент не авторизован для запроса кода авторизации с использованием данного метода;

- "access_denied": владелец ресурса или сервер авторизации отклонил запрос;

- "unsupported_response_type": сервер авторизации не поддерживает выдачу кода авторизации с использованием данного метода;

- "invalid_scope": запрошенная область действия недействительна, неизвестна или имеет неправильный формат;

- "server_error": сервер авторизации обнаружил непредвиденное состояние, которое не позволило ему выполнить запрос;

- "temporarily_unavailable": сервер авторизации в настоящее время не может обработать запрос из-за временной перегрузки или обслуживания сервера;

- "interaction_required": для авторизации на сервере авторизации требуется взаимодействие с конечным пользователем (значение параметра <prompt> запроса аутентификации равно "none", но запрос аутентификации не может быть выполнен без отображения пользовательского интерфейса для взаимодействия с конечным пользователем);

- "login_required": сервер авторизации требует аутентификации конечного пользователя (значение параметра <prompt> запроса аутентификации равно "none", но запрос аутентификации не может быть выполнен без отображения пользовательского интерфейса для аутентификации конечного пользователя);

- "account_selection_required": конечный пользователь должен выбрать сеанс на сервере авторизации (значение параметра <prompt> запроса аутентификации равно "none", но запрос аутентификации не может быть выполнен без отображения пользовательского интерфейса, запрашивающего сеанс);

- "consent_required": серверу авторизации требуется согласие конечного пользователя (значение параметра <prompt> запроса аутентификации равно "none", но запрос аутентификации не может быть выполнен без отображения пользовательского интерфейса для получения согласия конечного пользователя);

- "invalid_request_uri": попытка доступа по адресу <request_uri> в запросе авторизации возвращает ошибку или содержит неверные данные;

- "invalid_request_object": параметр <request> содержит недопустимый объект запроса;

- "request_not_supported": сервер авторизации не поддерживает использование параметра <request>;

- "request_uri_not_supported": сервер авторизации не поддерживает использование параметра <request_uri>;

- "registration_not_supported": сервер авторизации не поддерживает использование параметра <registration>.

5.4.2.10. Получив успешный ответ на запрос аутентификации, клиент проверяет его. Клиент должен игнорировать нераспознанные параметры ответа. Клиент должен проверить соответствие длин параметров установленным при разработке сервера авторизации ограничениям. Клиент должен проверить, совпадает ли значение параметра <state>, полученное в составе ответа, со значением параметра <state> в запросе аутентификации, переданным клиентом.

5.4.2.11. В случае успешной проверки ответа сервера авторизации клиент формирует и отправляет на адрес конечной точки токена запрос токена. Параметры запроса токена:

- <grant_type>: (обязательный) тип разрешения; в данном случае значением должна быть строка "authorization_code";

- <code>: (обязательный) значение кода авторизации, полученное от сервера авторизации;

- <redirect_uri>: (обязательный) URI переадресации, на который будет отправлен ответ; должен быть предварительно зарегистрирован на сервере авторизации; значение этого параметра должно совпадать со значением параметра <redirect_uri> запроса авторизации;

- <client_id>: (обязательный) идентификатор клиента, зарегистрированный сервером авторизации.

Примечание. Дополнительные сведения по запросу токена см. в [10] (пункт 4.1.3) и [11] (подпункт 3.1.3.1).

5.4.2.12. Сервер авторизации должен проверить запрос токена следующим образом:

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

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

- убедиться, что код авторизации действителен;

- убедиться, что код авторизации ранее не использовался;

- убедиться, что значение параметра <redirect_uri> совпадает со значением параметра <redirect_uri>, которое было включено в начальный запрос авторизации. Если значение параметра <redirect_uri> отсутствует при наличии только одного зарегистрированного значения <redirect_uri>, сервер авторизации может вернуть ошибку (так как клиент должен был включить параметр) или может работать без ошибки (так как OAuth 2.0 разрешает опускать этот параметр в таком случае);

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

- убедиться, что использованный код авторизации был выдан в ответ на запрос аутентификации OpenID Connect.

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

Примечание. Время действия кода авторизации определяется на этапе разработки сервера авторизации.

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

5.4.2.14. Получив и успешно проверив запрос токена, сервер авторизации генерирует ID токен (см. подпункт 5.4.2.16), токен доступа (см. подпункт 5.4.2.18), а также, если необходимо, токен обновления (см. подпункт 5.4.2.19) и возвращает их клиенту по адресу <redirect_uri> в теле HTTP ответа с кодом состояния 200 (ОК). В ответе используется тип формата "application/json". Ответ должен включать следующие поля и значения заголовка HTTP ответа:

Cache-Control: no-store

Pragma: no-cache

Параметры JSON структуры ответа на запрос токена:

- <access_token>: (обязательный) токен доступа;

- <token_type>: (обязательный) тип токена, должен иметь значение "Bearer";

- <expires_in>: (рекомендуемый) время жизни токена в секундах;

- <refresh_token>: (опциональный) токен обновления;

- <scope>: (опциональный) область действия токена доступа;

- <id_token>: (обязательный) ID токен, связанный с текущей сессией доступа.

В случае ошибки проверки запроса токена сервер авторизации должен ответить сообщением об ошибке. Параметры и формат сообщения об ошибке приведены в подпункте 5.4.2.9. В теле HTTP ответа используется тип "application/json" с кодом HTTP ответа 400.

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

5.4.2.15. Клиент должен проверять правильность ответа на запрос токена следующим образом:

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

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

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

- клиент должен проверить правильность ID токена согласно подпункту 5.4.2.17.

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

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

- <iss>: (обязательный) идентификатор эмитента (сервера авторизации), источника ответа; регистрозависимый URL-адрес, использующий схему https; содержит схему, хост и опционально компоненты номера порта и пути, но не компоненты запроса или фрагмента;

- <sub>: (обязательный) уникальный идентификатор субъекта, выданный сервером авторизации конечному пользователю; регистрозависимая строка длиной не более 255 символов ASCII;

- <aud>: (обязательный) аудитория, для которой предназначен данный ID токен; должна содержать идентификатор <client_id>; в общем случае значение <aud> представляет собой массив чувствительных к регистру строк; если есть только один элемент, значением <aud> может быть единственная строка;

- <exp>: (обязательный) время завершения срока действия, при наступлении и после наступления которого ID токен не должен приниматься к обработке; значением является число в формате JSON, представляющее количество секунд от 1970-01-01T0:0:0Z UTC до соответствующей даты/времени;

- <iat>: (обязательный) время, когда был выпущен токен; значением является число в формате JSON, представляющее количество секунд от 1970-01-01T0:0:0Z UTC до соответствующей даты/времени;

- <auth_time>: (обязательный, если в запросе аутентификации присутствует значение параметра <max_age>) время, когда выполнена аутентификация конечного пользователя; значением является число в формате JSON, представляющее количество секунд от 1970-01-01T0:0:0Z UTC до соответствующей даты/времени;

- <nonce>: строковое значение; равно значению параметра <nonce>, в запросе аутентификации; серверу авторизации следует включать этот параметр, если значение параметра <nonce> присутствует в соответствующем запросе аутентификации;

- <azp>: (опциональный) идентификатор клиента стороны, для которого был выпущен ID токен.

ID токен должен быть подписан с использованием JWS (см. пункт 5.7.1). Он может быть подписан с использованием JWS и затем зашифрован с использованием JWE (см. пункт 5.7.2), как структура Nested JWT (см. подраздел 5.7). При этом в ID токене не должна использоваться строка "none" в качестве значения параметра <alg>.

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

1 Если ID токен зашифрован, следует расшифровать его, используя ключи и алгоритмы, которые сервер авторизации должен был использовать для шифрования ID токена как JWE (см. 5.8.1 и 5.7.2).

2 Идентификатор эмитента (сервера авторизации), полученный при регистрации клиента, должен точно соответствовать значению параметра <iss> ID токена.

3 Клиент должен убедиться, что значение параметра <aud> содержит значение <client_id>, полученное клиентом от сервера авторизации при регистрации. ID токен должен быть отклонен, если <aud> не содержит значение <client_id> клиента.

4 Если ID токен содержит несколько компонент в составе параметра <aud>, клиент должен проверить наличие параметра <azp> и при его наличии проверить, что значение равно <client_id>.

5 Клиент должен проверить подпись структуры JWS ID токена, применяя алгоритм, указанный в параметре <alg>, используя ключ, предоставленный сервером авторизации. Если ID токен получен посредством прямого обмена данными между клиентом и конечной точкой токена, проверка сообщений протокола TLS от сервера может использоваться для проверки эмитента вместо проверки подписи токена.

6 Значение параметра <alg> должно быть значением по умолчанию или алгоритмом, зарегистрированным клиентом в значении параметра <id_token_signed_response_alg> во время регистрации.

7 Если в значении параметра <alg> указан алгоритм MAC, то в качестве ключа должны использоваться октеты UTF-8 представления <client_secret>, соответствующего <client_id> клиента.

8 Текущее время проверки должно быть раньше времени, указанного в значении параметра <exp>.

9 Для отзыва токенов, выпущенных слишком давно, может использоваться параметр <iat>, который ограничивает время, необходимое для хранения значений параметра <nonce>. Приемлемый диапазон определяется при разработке сервера авторизации.

10 Если в запросе аутентификации, отосланном клиентом в адрес сервера авторизации, указано значение параметра <nonce>, в структуре ID токена также должно присутствовать значение параметра <nonce>. Следует убедиться, что эти два значения совпадают.

11 Если запрашивалось значение параметра <auth_time> либо посредством специального запроса этого параметра, либо указанием параметра <max_age> в запросе аутентификации, клиенту следует проверить значение параметра <auth_time> на допустимость диапазону <max_age> и сделать запрос повторной аутентификации, если он определяет, что с момента последней аутентификации конечного пользователя прошло слишком много времени.

Примечание. Дополнительные сведения об использовании ID токена см. в разделе 2 [11].

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

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

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

Примечание. Рекомендации по использованию токенов доступа см. в [11] (подраздел 16.18).

5.4.2.19. Токен обновления (refresh token) - это свидетельство, используемое для получения токенов доступа. Токен обновления выдается клиенту сервером авторизации и используется для получения нового токена доступа, когда текущий токен доступа становится недействительным или истекает его срок действия, или для получения дополнительных токенов доступа с идентичной или более узкой областью действия (токены доступа могут иметь более короткий срок службы и меньше разрешений на доступ, чем разрешено владельцем ресурса). Выдача токена обновления необязательна и выполняется по усмотрению сервера авторизации. Если сервер авторизации выдает токен обновления, он включается в ответ при выдаче токена доступа. Данная функциональность не входит в область действия настоящего документа и определяется на этапе разработки сервера авторизации, исходя из его прикладных целей и задач.

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

Решение о необходимости выдачи токена обновления принимается на этапе разработки сервера авторизации.

5.4.2.20. Клиент может получить информацию о конечном пользователе, либо извлекая ее из параметров ID токена, либо с помощью запроса к конечной точке UserInfo сервера авторизации.

Чтобы получить значение параметра информации о конечном пользователе, клиент отправляет запрос конечной точке UserInfo, используя токен доступа, полученный при аутентификации на сервере авторизации. Значения параметров в ответ возвращаются в виде JSON объекта, который содержит коллекцию пар "имя и значение параметра". Конечная точка UserInfo должна принимать токены доступа на предъявителя ("Bearer").

Конечная точка UserInfo должна поддерживать использование методов HTTP GET и HTTP POST. Взаимодействие между клиентом и сервером авторизации при обращении клиента на точку UserInfo должно быть защищено протоколом TLS.

Примечание. Сведения об алгоритмах работы в конечной точке UserInfo приведены в [11] (подраздел 5.3).

5.4.3. Гибридный сценарий аутентификации

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

Гибридный сценарий состоит из следующих действий:

1 Клиент генерирует запрос аутентификации, содержащий желаемые параметры запроса.

2 Клиент отправляет запрос на сервер авторизации.

3 Сервер авторизации аутентифицирует конечного пользователя.

4 Сервер авторизации получает согласие/авторизацию конечного пользователя.

5 Сервер авторизации возвращает конечного пользователя на клиент с передачей кода авторизации и в зависимости от типа ответа - одного или нескольких дополнительных параметров.

6 Клиент запрашивает ответ на конечной точке токена, используя код авторизации.

7 Клиент получает ответ, содержащий ID токен и токен доступа.

8 Клиент проверяет ID токен и извлекает идентификатор субъекта конечного пользователя (значение параметра <sub>).

5.4.3.2. При использовании гибридного сценария действия сервера авторизации и клиента, связанные с формированием запроса аутентификации, его передачей, проверкой, а также аутентификацией пользователя и получением его согласия, в целом те же, что и в сценарии с кодом авторизации (см. подпункты 5.4.2.2 - 5.4.2.7). При этом параметр <response_type> запроса аутентификации должен иметь одно из следующих значений: "code id_token", либо "code token", либо "code id_token token".

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

В случае успешного ответа на запрос аутентификации все параметры ответа добавляются к компоненте фрагмента URI переадресации. При этом клиенту возвращаются значения следующих параметров:

- <access_token>: токен доступа; обязательный, если значение параметра <response_type> запроса аутентификации равно "code token" или "code id_token token";

- <token_type>: тип токена; обязательный, если значение параметра <response_type> запроса аутентификации равно "code token" или "code id_token token"; если присутствует, значением должен быть тип "Bearer";

- <id_token>: ID токен; обязательный, если значением <response_type> является "code id_token" или "code id_token token";

- <code>: (обязательный) код авторизации;

- <state>: (обязательный, если в составе запроса аутентификации присутствует значение параметра <state>) значение параметра <state> из запроса аутентификации (см. подпункт 5.4.2.2); клиент должен проверить равенство возвращенного значения параметра <state> значению параметра <state>, переданному им в составе запроса аутентификации;

- <expires_in>: (опциональный) время жизни токена доступа в секундах с момента генерации ответа.

5.4.3.4. Формат ID токена в данном сценарии аналогичен подпункту 5.4.2.16 со следующими дополнениями:

- параметр <nonce> обязательный;

- добавлен обязательный параметр <at_hash>: хэш-значение токена доступа; вычисляется сервером авторизации и проверяется клиентом как Base64url кодирование левой половины хэш-кода октетов ASCII представления значения <access_token>; если токен доступа не запрашивается, значение параметра <at_hash> должно отсутствовать;

- добавлен обязательный параметр <c_hash>, значение которого вычисляется сервером авторизации и проверяется клиентом как Base64url кодирование левой половины значения хэш-функции октетов ASCII представления значения параметра <code>.

5.4.3.5. Клиент должен убедиться в правильности ответа аутентификации:

- следуя правилам 5.4.2.15;

- проверив целостность токена доступа (если значение параметра <response_type> запроса аутентификации равно "code token" или "code id_token token") путем сравнения значения Base64url кодирования левой половины хэш-кода полученного значения <access_token> с полученным значением параметра <at_hash>;

- проверив целостность кода авторизации (если значение параметра <response_type> запроса аутентификации равно "code id_token" или "code id_token token") путем сравнения значения Base64url кодирования левой половины хэш-кода полученного значения <code> с полученным значением параметра <c_hash>.

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

Если ID токен возвращается как из конечной точки авторизации, так и из конечной точки токена, что имеет место для одного из двух значений <response_type>: "code id_token" и "code id_token token", значения <iss> и <sub> должны быть идентичны в обоих 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 формате перечислены метаданные сервера авторизации. В частности, в конфигурации перечислены значения таких параметров:

- <issuer>: (обязательный) https URL адрес, являющийся идентификатором эмитента (Issuer Identifier); далее это значение должно быть указано в качестве параметра <iss> в ID токенах; получив ответ, клиент должен проверить совпадение значения параметра <issuer> с адресом сервера авторизации, на который он делал запрос;

- <authorization_endpoint>: (обязательный) 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 массив значений параметра <scope>, которые поддерживает сервер авторизации;

- <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";

- <application_type>: (опциональный) тип клиента ("native" или "web");

- <contacts>: (опциональный) массив адресов электронной почты лиц, ответственных за этого клиента;

- <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; публикуемые сертификаты должны передаваться доверенным образом;

- <jwks>: (опциональный) документ JWK Set, передаваемый по значению; параметры <jwks_uri> и <jwks> не должны одновременно присутствовать в метаданных клиента; сертификаты открытых ключей должны передаваться доверенным образом;

- <default_max_age>: (опциональный) максимальный возраст аутентификации по умолчанию; указывает, что конечный пользователь должен быть повторно аутентифицирован, если с момента его аутентификации прошло более чем указанное количество секунд;

- <require_auth_time>: (опциональный) логическое значение, указывающее, требуется ли указывать параметр <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> и <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):

- <iss>: (обязательный) источник; должен содержать <client_id> клиента;

- <sub>: (обязательный) субъект; должен содержать <client_id> клиента;

- <aud>: (обязательный) аудитория; значением должен быть URL-адрес конечной точки токена сервера авторизации;

- <jti>: (обязательный) идентификатор JWT; уникальный идентификатор токена, который необходим для предотвращения повторного использования токена;

- <exp>: (обязательный) время, по истечении которого токен не должен быть принят к обработке;

- <iat>: (опциональный) время выпуска 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 должен содержать значение параметра <iss> (эмитент).

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

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

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

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

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

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

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

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

В случае ошибки проверки JWT сервер авторизации должен ответить кодом ошибки "invalid_client" в качестве значения параметра <error> (см. подпункт 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, либо непосредственно публикуя их в качестве значения параметра <jwks> в формате 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). В этом случае значение заголовка <Authorization> должно иметь формат:

Authorization = "Bearer" || <token>,

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

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

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

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

- поле <Content-Type> заголовка HTTP-запроса имеет значение "application/x-www-form-urlencoded";

- тело запроса соответствует требованиям кодирования контента "application/x-www-form-urlencoded";

- тело HTTP-запроса состоит из одной части, то есть запрос не является запросом типа "multipart/form-data";

- содержимое тела запроса должно состоять исключительно из ASCII-символов;

- должен использоваться HTTP метод, семантика тела запроса которого строго определена. В частности, это означает, что HTTP метод GET не должен использоваться.

Клиенту не рекомендуется использовать такой метод авторизации, кроме случаев, когда браузер не имеет доступа к <Authorization> заголовку 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 Header>: JOSE заголовок - JSON-объект, содержащий параметры, описывающие криптографические операции и их параметры (см. подпункт 5.7.1.4);

- <JWS Payload>: функциональное содержимое JWS (полезная нагрузка) - последовательность октетов, подлежащих защите, другими словами - сообщение; функциональное содержимое может состоять из произвольной последовательности октетов;

- <JWS Signature>: цифровая подпись или код аутентификации сообщений, вычисленные на основе защищенного заголовка JWS и функционального содержимого JWS.

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

- <JWS Protected Header>: защищенный заголовок JWS - JSON-объект, содержащий параметры заголовка, целостность которых защищена цифровой подписью JWS или операцией MAC;

- <JWS Unprotected Header>: незащищенный заголовок JWS - JSON-объект, который содержит параметры заголовка, целостность которых не обеспечивается.

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

- компактная сериализация - представление JWS в виде компактной URL-строки,

- JSON-сериализация - представление JWS в виде объекта JSON.

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

BASE64URL(UTF8(<JWS Protected Header>) || '.' || BASE64URL
(<JWS Payload>) || '.' || BASE64URL(<JWS Signature>)

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

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

- <protected>: со значением BASE64URL(UTF8(<JWS Protected Header>)), если значение параметра <JWS Protected Header> не пустое; иначе значение параметра <protected> должно отсутствовать;

- <header>: со значением <JWS Unprotected Header>; этот параметр должен присутствовать, если значение <JWS Unprotected Header> не пустое, иначе он должен отсутствовать;

- <payload>: (обязательный) со значением BASE64URL(<JWS Payload>);

- <signature>: (обязательный) со значением BASE64URL(<JWS Signature>).

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

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

- <alg>: (обязательный) идентификатор криптографического алгоритма цифровой подписи или MAC, используемого для защиты JWS;

- <jku>: (опциональный) URI, который указывает на ресурс, где находится ключ проверки подписи в представлении JWK (см. пункт 5.7.3), который используется для проверки цифровой подписи JWS;

- <jwk>: (опциональный) ключ проверки подписи в представлении JWK (см. пункт 5.7.3), который используется для проверки цифровой подписи JWS;

- <kid>: (опциональный) идентификатор ключа, который используется для защиты JWS;

- <x5u>: (опциональный) URI, который ссылается на ресурс сертификата формата X.509 или цепочки сертификатов ключа проверки цифровой подписи JWS; данный ресурс должен содержать представление сертификата или цепочки сертификатов в соответствии с RFC 5280 [32] в PEM кодировании; сертификат ключа проверки цифровой подписи JWS должен быть первым сертификатом; в цепочке сертификатов каждый последующий сертификат должен использоваться для сертификации предыдущего; получатель должен проверить цепочку сертификатов в соответствии с RFC 5280 [32], считать сертификат или цепочку сертификатов и подпись JWS недействительными в случае отрицательного результата проверки; для получения ресурса должен использоваться HTTP запрос GET и протокол TLS;

- <x5c>: (опциональный) сертификат формата X.509 или цепочка сертификатов проверки цифровой подписи JWS; сертификат или цепочка сертификатов представлены в виде JSON-массива строк значений сертификата; каждая строка массива содержит кодировку Base64 (раздел 4 RFC 4648 [14], не Base64url кодирование) значение DER-представления сертификата формата X.509; сертификат ключа проверки цифровой подписи JWS должен быть первым сертификатом; в цепочке сертификатов каждый последующий сертификат должен использоваться для сертификации предыдущего; получатель должен проверить цепочку сертификатов в соответствии с RFC 5280 [32], считать сертификат или цепочку сертификатов и подпись JWS недействительными в случае отрицательного результата проверки;

- <typ> (Type): (опциональный) тип сериализации ("JOSE" - компактная сериализация, "JOSE+-JSON" - JSON-сериализация);

- <cty> (Content Type): (опциональный) тип (media type) функционального содержимого JWS; как правило, используется, если в приложении несколько типов объектов могут быть представлены в качестве содержимого <JWS Payload>;

- <crit>: (опциональный) JSON-массив имен критичных параметров заголовка; если какой-то из параметров, чье имя внесено в этот массив, не поддерживается или не понято получателем, JWS считается недействительной; если параметр <crit> присутствует, он должен быть понят и обработан получателем.

5.7.1.5. Значение цифровой подписи или MAC <JWS Signature> вычисляется с помощью алгоритма, указанного значением параметра алгоритма <alg>, используя на входе алгоритма подписи (MAC) ключ, идентифицируемый параметрами <jku>, <jwk>, <kid>, <x5u>, <x5c>, и следующую подписываемую последовательность октетов:

ASCII (BASE64URL (UTF8((<JWS Protected Header>))
|| '.' || BASE64URL(<JWS Payload>))

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

Примечания

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

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

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

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

Структура JWE:

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

- <JWE Encrypted Key>: зашифрованный ключ защиты содержимого JWE для каждого получателя;

- <JWE Initialization Vector>: синхропосылка (вектор инициализации) JWE;

- <JWE AAD>: дополнительные аутентифицируемые, не шифруемые данные JWE;

- <JWE Ciphertext>: шифротекст JWE;

- <JWE Authentication Tag>: имитовставка JWE.

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

- <JWE Protected Header>: защищенный заголовок JWE, целостность значения которого будет защищаться JWE;

- <JWE Shared Unprotected Header>: общий незащищенный заголовок JWE;

- <JWE Per-Recipient Unprotected Header>: незащищенный заголовок для каждого получателя JWE.

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

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

BASE64URL(UTF8(<JWE Protected Header>)) || '.' ||
BASE64URL(<JWE Encrypted Key>) || '.' || BASE64URL
(<JWE Initialization Vector>) || '.' || BASE64URL (<JWE
Ciphertext>) || '.' || BASE64URL(<JWE Authentication Tag>)

Компактная сериализация не поддерживает параметры <JWE Shared Unprotected Header>, <JWE Per-Recipient Unprotected Header> и <JWE AAD>. Кроме того, она предполагает одного получателя сообщения.

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

- <protected>: если заголовок <JWE Protected Header> не пустой, этот параметр должен присутствовать со значением BASE64URL(UTF8(<JWE Protected Header>)); иначе этот параметр должен быть опущен;

- <unprotected>: если заголовок <JWE Shared Unprotected Header> не пустой, этот параметр должен присутствовать со значением <JWE Shared Unprotected Header>; иначе этот параметр должен быть опущен; как правило, это JSON-объект;

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

- <header>: если заголовок <JWE Per-Recipient Unprotected Header> не пустой, этот параметр должен присутствовать со значением <JWE Per-Recipient Unprotected Header>; иначе этот параметр должен быть опущен; как правило, это JSON-объект;

- <encrypted_key>: если значение <JWE Encrypted Key> не пустое, этот параметр должен присутствовать со значением BASE64URL(<JWE Encrypted Key>); иначе этот параметр должен быть опущен;

- <iv>: если значение <JWE Initialization Vector> не пустое, этот параметр должен присутствовать со значением BASE64URL(<JWE Initialization Vector>); иначе этот параметр должен быть опущен;

- <aad>: если значение <JWE AAD> не пустое, этот параметр должен присутствовать со значением BASE64URL(<JWE AAD>); иначе этот параметр должен быть опущен;

- <ciphertext>: (обязательный) шифротекст со значением BASE64URL (<JWE Ciphertext>);

- <tag>: если значение <JWE Authentication Tag> не пустое, этот параметр должен присутствовать со значением BASE64URL(<JWE Authentication Tag>); иначе этот параметр должен быть опущен.

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

- <enc>: (обязательный) идентификатор алгоритма шифрования, используемого для выполнения аутентифицированного шифрования открытого текста; этот параметр должен быть понят и обработан получателем;

- <zip>: (опциональный) идентификатор алгоритма сжатия, который применяется к незашифрованному тексту перед шифрованием; определено единственное значение: "DEF" - алгоритм сжатия DEFLATE; если значение этого параметра отсутствует, выполняется шифрование открытого текста без сжатия;

- <alg>, <jku>, <jwk>, <kid>, <x5u>, <x5c>, <typ>, <cty>, <crit>: как в JWS (см. пункт 5.7.1); при этом параметры < jku>, <jwk>, <kid>, <x5u>, <x5c> определяют открытый ключ, который был использован при формировании ключа шифрования, получатель может воспользоваться этой информацией, чтобы выбрать соответствующий закрытый ключ.

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

- в соответствии с идентификатором алгоритма шифрования вычислить ключ шифрования содержимого CEK;

- если используется алгоритм с шифрованием ключа, зашифровать ключ CEK, положив значением <JWE Encrypted Key> результат шифрования; если алгоритм шифрования не предполагает шифрования ключа, положить значение <JWE Encrypted Key> пустым;

- если требуется для алгоритма шифрования, сгенерировать значение случайной синхропосылки <JWE Initialization Vector> необходимой длины; иначе значение <JWE Initialization Vector> должно быть пустое;

- если указано значение параметра "zip", положить M - последовательность октетов, представляющих сжатый открытый текст; иначе M - последовательность октетов, представляющих открытый текст;

- зашифровать M с помощью алгоритма, который идентифицирован параметрами <alg> и <enc>, с использованием значений ключа CEK, синхропосылки <JWE Initialization Vector> и <JWE AAD>; результат - шифротекст <JWE Ciphertext> и имитовставка <JWE Authentication Tag>.

Расшифрование выполняет получатель 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 входят следующие параметры:

- <kty>: (обязательный) тип ключа; определены следующие значения:

- "EC": ключ для криптографического алгоритма на базе эллиптической кривой,

- "oct": последовательность октетов, используемая для представления симметричного ключа;

- "use": (опциональный) предполагаемое использование открытого ключа; определены следующие значения:

- "sig" - подпись,

- "enc" - шифрование;

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

- "sign" - вычисление цифровой подписи или кода аутентификации сообщений,

- "verify" - проверка цифровой подписи или кода аутентификации сообщений,

- "encrypt" - шифрование контента,

- "decrypt" - расшифрование контента и проверка расшифрованного, если возможно,

- "wrapKey" - шифрование ключа,

- "unwrapKey" - расшифрование ключа и проверка расшифрованного, если возможно,

- "deriveKey" - вычисление производного ключа,

- "deriveBits" - вычисление производных битов не для использования в качестве ключа;

- <alg> - (опциональный) идентифицирует криптографический алгоритм, в котором предполагается использование ключа;

- <kid> - (опциональный) идентификатор ключа; используется для того, чтобы выбрать нужный ключ в документе JWK Set;

- <x5u>, <x5c>, <x5t>, <x5t#S256>: (опциональные) как в JWS (см. пункт 5.7.1).

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

5.7.3.3. JSON-структура набора ключей JWK Set состоит из одного параметра <keys>, который является 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 каждого ключа должно быть указано значение параметра <use>. Не допускается использование одного и того же ключа как для целей подписи, так и для шифрования. Параметр JWK <x5c> может использоваться для предоставления ключей в формате сертификата 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:

- <iss>: (опциональный) идентификатор эмитента JWT (сервера авторизации, выдавшего его);

- <sub>: (опциональный) идентификатор субъекта JWT;

- <aud>: (опциональный) перечень идентификаторов получателей, которым предназначен JWT;

- <exp>: (опциональный) время завершения срока действия JWT в секундах;

- <nbf>: (опциональный) время, до которого JWT не должен приниматься к обработке;

- <iat>: (опциональный) время выпуска JWT;

- <jti>: (опциональный) идентификатор JWT.

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

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

5.7.4.3. В JOSE-заголовке JWT независимо от типа (JWS или JWE) используются два параметра: <typ> (рекомендуется использовать строку "JWT") и <cty> (при наличии вложенной подписи или шифрования его значением должна быть строка "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-заголовке должно присутствовать значение параметра <kid>. Параметр <use> соответствующего ключа должен указывать на то, что этот ключ поддерживает алгоритм цифровой подписи ("sig").

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

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

5.8.1.4. Шифрование

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

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

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

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

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

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

При смене ключей шифрования следует использовать процесс, отличный от процесса смены ключей цифровой подписи, поскольку процесс смены открытого ключа получателя запускает получатель, не являющийся отправителем (шифрующим), и, таким образом, отправитель не может полагаться на изменение параметра <kid> в качестве сигнала о необходимости смены ключей. Шифрующий продолжает использовать прежний параметр <kid> в заголовке 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), в качестве значения параметра токена <cnf> используется строка, идентифицирующая метод подтверждения на основе хэш-функции с длиной образа не менее 256 битов, и значение хэш-кода, которое формируется как Base64url кодирование значения хэш-функции, вычисленное от DER-представления (по ГОСТ Р ИСО/МЭК 8825-1) сертификата формата Х.509.

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

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

{
"iss": "https://server.example.com",
"sub": "ty.webb@example.com",
"exp": 1493726400,
"nbf": 1493722800,
"cnf": {
"x5t#S256": "bwcK0esc3ACC3DB2Y5_LESsXE8o91tc05O89jdN-dg2"
}
}

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

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

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

Примечания

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

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

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

HTTP/1.1 200 OK
Content-Type: application/json
{
"active": true,
"iss": "https://server.example.com",
"sub": "ty.webb@example.com",
"exp": 1493726400,
"nbf": 1493722800,
"cnf":{
"x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o91tc05O89jdN-dg2"
}
}

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, на усмотрение сервера авторизации остается принятие решения относительно того, следует ли возвращать ошибку или выдать токен, не связанный с сертификатом.