6.2. ПОЛОЖЕНИЯ ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ АВТОРИЗАЦИИ
6.2. ПОЛОЖЕНИЯ ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ АВТОРИЗАЦИИ 
6.2.1. В связи с тем, что на основании стандарта ФАПИ.СЕК может предоставляться потенциально чувствительная информация, она требует более высокого уровня защиты, чем базовые требования OAuth 2.0.
6.2.2. Сервер авторизации:
1 должен поддерживать конфиденциальных клиентов;
2 не должен поддерживать доступ в режиме чтения со стороны публичных клиентов;
3 в случае использования симметричного ключа должен предоставлять ключ клиента <client_secret", соответствующий требованиям пункта 5.8.2;
4 должен аутентифицировать конфиденциального клиента в конечной точке токена, используя один из следующих методов:
- TLS с взаимной аутентификацией сторон взаимодействия протокола OAuth 2.0 и его профилей, включая OIDC, как определено в пунктах 5.5.4 или 5.5.5;
<client_secret_JWT> или <private_key_JWT>, как определено в пунктах 5.5.2 и 5.5.3;
5 должен требовать ключ, размер которого составляет 256 бит или больше, если для аутентификации клиента используются алгоритмы, основанные на использовании эллиптической кривой;
6 должен требовать предварительной регистрации URI переадресации клиента;
7 должен требовать наличия параметра <redirect_URI> в запросе аутентификации (см. подпункт 5.4.2.2);
8 должен требовать, чтобы значение параметра <redirect_URI> точно соответствовало одному из предварительно зарегистрированных URI переадресации клиента (см. подпункт 5.4.4.5);
9 должен требовать явного согласия конечного пользователя на авторизацию доступа к запрашиваемой области действия (параметр <scope>), если она не была ранее авторизована;
10 должен исключать повторное использование кодов авторизации в соответствии с рекомендациями подпункта 5.4.2.13;
11 должен возвращать ответ с токеном доступа и, если это установлено при разработке сервера авторизации, с токеном обновления в соответствии с подпунктом 5.4.2.10;
12 должен возвращать список предоставленных областей действия (параметр <scope>) по выданному токену доступа (см. подпункт 5.4.2.20);
13 должен предоставлять непредсказуемые значения токенов доступа как минимум с 128-битной энтропией; при этом рекомендуется генерировать токены с энтропией не ниже 160 бит;
Примечание. Здесь и далее значения токенов доступа и параметров <nonce> должны генерироваться с помощью СКЗИ, используемого при реализации криптографической защиты информации.
14 рекомендуется уведомлять владельца ресурса о том, что клиент запрашивает долгосрочное разрешение на доступ (см. подпункт 5.4.2.19);
15 рекомендуется предоставлять конечному пользователю механизм аннулирования токенов доступа и токенов обновления, выданных клиенту (см. подпункт 5.4.2.19);
16 при обращении к методам аутентификации клиента, которые могут передавать идентификатор клиента более чем одним разрешенным способом, в случае предоставления несовпадающих идентификаторов клиента должен возвращать код ошибки "invalid_client";
17 должен требовать, чтобы сервисы по адресу URI переадресации использовали протокол HTTPS.
6.2.3. При предоставлении клиенту в ответе на запрос токена доступа идентификатор аутентифицированного пользователя сервер авторизации:
1 должен поддерживать запрос аутентификации в соответствии с подпунктом 5.4.2.2;
2 должен осуществлять проверку запроса аутентификации в соответствии с подпунктом 5.4.2.5;
3 должен предоставлять ответ на запрос аутентификации в соответствии с подпунктами 5.4.2.7 и 5.4.2.8 в зависимости от результата аутентификации;
4 должен осуществлять проверку запроса токена в соответствии с подпунктом 5.4.2.12;
5 если параметр <scope> запроса аутентификации включает "openid", должен генерировать ID токен в составе ответа на запрос токена в соответствии с подпунктом 5.4.2.14; при этом значение параметра <sub> должно соответствовать аутентифицированному пользователю.
6.2.4. Клиент:
1 может использовать механизмы, определенные в разделе 7;
2 должен использовать разные URI переадресации для каждого сервера авторизации, на котором зарегистрирован клиент;
3 должен поддерживать следующие методы аутентификации в конечной точке токена:
- TLS с взаимной аутентификацией клиента OAuth, как определено в пунктах 5.5.4 и 5.5.5;
- <client_secret_JWT> или <private_key_JWT>, как определено в пунктах 5.5.2 и 5.5.3;
4 должен использовать ключи криптографии с эллиптической кривой с минимальным размером 256 бит, если используются криптографические алгоритмы на основе арифметики эллиптической кривой;
5 должен проверять, что значение ключа клиента <client_secret> имеет длину не менее 256 бит, если используется криптография с симметричным ключом.
Если по результатам аутентификации клиент запрашивает получение постоянного идентификатора аутентифицированного клиента, клиент:
6 должен включать строку "openid" в перечень значений параметра <scope>;
7 должен включать параметр <nonce> (см. подпункт 5.4.2.2) в состав запроса аутентификации.
Если строка "openid" не включена в перечень значений параметра <scope>, конфиденциальный клиент:
8 должен включать параметр <state> (см. подпункт 5.4.2.2).
