7.2. ПОЛОЖЕНИЯ ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ АВТОРИЗАЦИИ
7.2. ПОЛОЖЕНИЯ ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ АВТОРИЗАЦИИ 
7.2.1. Доступ для чтения и записи представляет повышенный риск; соответственно, требуемый уровень защиты выше, чем в случае доступа только для чтения.
Данный документ предписывает выполнение требований пунктов 7.2.2, 7.2.3 и 7.2.4 при использовании технологии авторизации OAuth 2.0 для защиты API чтения и записи.
7.2.2. Сервер авторизации должен поддерживать положения, определенные в 6.2.2.
Кроме того, для выполнения операции записи сервер авторизации:
1 должен требовать, чтобы параметр <request> или <request_URI> передавался как токен JWT (см. 5.7.4), подписанный в соответствии с JWS (см. пункт 5.7.1);
2 должен требовать в качестве значения параметра <response_type>: "code id_token token";
3 должен возвращать ID токен как отдельную подпись (detached signature) ответа на запрос авторизации;
4 если клиент предоставил значение <state>, для защиты этого значения должен включать в ID токен значение параметра <s_hash> (см. пункт 7.1.2) - хэш-код параметра <state>. Значение <s_hash> может быть опущено в ID токене, возвращенном из конечной точки токена, когда <s_hash> присутствует в ID токене, возвращенном из конечной точки авторизации;
5 должен генерировать только код авторизации, токен доступа и токен обновления, которые связаны с владельцем ключа, чей сертификат был предъявлен серверу на этапе установления TLS-соединения;
6 должен поддерживать механизм подтверждения владения ключом с привязкой токена к MTLS сертификату (см. пункт 5.8.4) или с привязкой токенов к TLS-соединению;
Примечание. Общие сведения о технологии привязки токенов OAuth 2.0 к TLS-соединению приведены в документе "OAuth 2.0 Token Binding" [41].
7 должен поддерживать подписанные ID токены;
8 рекомендуется поддерживать подписанные и зашифрованные ID токены;
9 должен требовать, чтобы все параметры передавались в качестве атрибутов подписанного объекта запроса (см. подпункт 5.4.2.4), передаваемого в параметре <request> или <request_URI>;
10 может поддерживать конечную точку API для обработки запроса, включающего в качестве своей компоненты <payload> объект запроса, как описано в подразделе 7.4;
11 должен требовать, чтобы объект запроса (см. подпункт 5.4.2.4) содержал параметр <exp>;
12 должен аутентифицировать конфиденциального клиента в конечной точке токена, используя один из следующих методов (это отменяет перечисление 4 в пункте 6.2.2):
- TLS с взаимной аутентификацией клиента OAuth, как определено в пункте 5.5.4 или 5.5.5;
- <private_key_JWT>, как определено в пункте 5.5.3.
7.2.3. Клиент должен поддерживать положения пункта 6.2.4.
Кроме того, для выполнения операций записи клиент:
1 должен поддерживать механизм подтверждения владения ключом с привязкой токена к MTLS сертификату (см. пункт 5.8.4) или с привязкой токена к TLS-соединению.
Примечание. В случае конфиденциального клиента MTLS может также использоваться как механизм аутентификации клиента (см. пункты 5.5.4 или 5.5.5).
2 должен включать в запрос аутентификации параметр <request> или <request_URI> (см. подпункт 5.4.2.4);
3 должен требовать, чтобы конечные точки возвращали ID токен, подписанный с использованием JWS (см. пункт 5.7.4);
4 используя ID токен в качестве отдельной подписи, должен проверять, что ответ на запрос авторизации не был подделан;
5 при проверке ID токена должен проверять значение параметра <state> запроса аутентификации путем проверки значения параметра <s_hash> (пункт 7.1.2);
6 должен отправлять все параметры в составе подписанного объекта запроса авторизации (подпункт 5.4.2.4);
7 должен дополнительно отправлять дубликаты параметров с использованием синтаксиса запроса OAuth 2.0, когда этого требует спецификация OAuth;
8 должен требовать, чтобы конечные точки возвращали подписанные с использованием JWS (пункт 5.7.1) и зашифрованные с использованием JWE (пункт 5.7.2) ID токены, необходимые для обеспечения защиты любых персональных данных, содержащихся в ID токене, предоставленном в качестве отдельной подписи в ответе на запрос авторизации.
Примечания
1 Общие сведения об алгоритмах проверки запроса авторизации приведены в подпункте 5.4.2.5, дополнительные сведения приведены в [11] (подпункты 3.2.2.11, 3.3.2.12).
2 Дополнительные сведения о передаче объекта запроса по значению приведены в [11] (подраздел 6.1).
7.2.4. Режим защищенного ответа на запрос авторизации на базе JWT
В дополнение к положениям, представленным в пункте 7.2.2, сервер авторизации может обеспечивать защиту ответов на запрос авторизации клиентов, используя JARM (см. раздел 8).
JARM позволяет клиенту потребовать от сервера авторизации, чтобы он кодировал ответы на запросы авторизации (любого типа), используя JWT. Это альтернатива использованию ID токенов в качестве отдельных подписей для обеспечения безопасности ответов на запросы авторизации.
Серверу авторизации рекомендуется известить о поддержке режимов ответа JARM, используя параметр метаданных <response_modes_supported> (см. подпункт 5.4.4.1).
В случае использования JARM для защиты ответов на запросы авторизации перечисления 2, 3 и 4 из пункта 7.2.2 не применяются. Например, клиенты могут использовать JARM в сочетании с типом ответа "code".
