7.3. Положения об обеспечении безопасности клиента
7.3.1. Клиент должен поддерживать положения подраздела 6.3, за исключением поддержки PKCE.
Кроме того, конфиденциальный клиент:
1. Должен поддерживать MTLS токены доступа с привязкой к сертификату (пункт 5.8.4).
2. Должен включать в состав запроса аутентификации один из параметров <request> или <request_uri>.
3. Должен убедиться, что сервер авторизации аутентифицировал пользователя на требуемом уровне доверия в соответствии с [6] для предполагаемой цели клиента (допустимые значения: параметр <acr_values> запроса аутентификации; фактическое значение: параметр <acr> ID токена).
4. Должен отправлять все параметры запроса в составе подписанного объекта запроса аутентификации (подпункт 5.4.2.3).
5. Должен дополнительно отправлять дубликаты параметров/значений <response_type>, <client_id> и <scope>, используя синтаксис запроса OAuth 2.0 (подраздел 6.1 [17]).
6. Должен отправлять параметр <aud> в объекте запроса в качестве URL-идентификатора эмитента.
7. Должен отправлять в объекте запроса параметр <exp> c временем жизни не более 60 минут.
8. Должен посылать в составе объекта запроса параметр <nbf>.
7.3.2. ID токен в качестве отделенной подписи
Кроме того, если используется <response_type> = "code id_token", клиент:
1. Должен включить строку "openid" в значение параметра <scope>, чтобы активировать поддержку OIDC.
2. Должен требовать, чтобы от конечных точек возвращался ID токен, подписанный JWS.
3. Должен проверить, что ответ авторизации не был подделан (ID токен в качестве отделенной подписи).
4. Должен проверять, что значение <s_hash> равно значению, вычисленному на основе значения <state> в ответе авторизации.
5. Должен поддерживать подписанные, а также подписанные и зашифрованные ID токены.
7.3.3. JARM
Кроме того, если значение <response_type> = "code" используется в сочетании со значением <response_mode> = "jwt", клиент должен проверять ответы авторизации в соответствии с пунктом 6.4.4 [5] и пунктом 5.4.5.