7.2. Положения об обеспечении безопасности сервера авторизации
7.2. Положения об обеспечении безопасности сервера авторизации 
7.2.1. Сервер авторизации должен поддерживать положения, указанные в подразделе 6.2.
При этом положение пункта 6.2.1 в части перечисления 6 (PKCE) не должно использоваться.
Кроме того, сервер авторизации:
1. Должен требовать подписанный JWS (пункт 5.7.1) объект запроса JWT (пункт 5.7.4), переданный по значению с параметром <request> или по ссылке с параметром <request_uri>.
2. Должен требовать:
a. значения <response_type> = "code id_token" (Режим 3 [5]), или
b. значения <response_type> = "code" в сочетании со значением <response_mode> = "jwt" (Режим 2 [5]).
3. Должен выдавать только токены доступа с ограничением отправителя (sender-constrained access tokens) (пункт 5.8.4).
4. Должен поддерживать MTLS как механизм для ограничения легитимных отправителей токенов доступа (пункт 5.8.4).
5. Должен использовать только параметры, включенные в подписанный объект запроса, переданный через параметр <request> или <request_uri>.
6. Должен требовать, чтобы объект запроса содержал параметр <exp> с временем жизни не более 60 минут, начиная со значения параметра <nbf>.
7. В отличие от требований подраздела 6.2, должен аутентифицировать конфиденциального клиента, используя один из методов, указанных в подразделе 5.5:
- "private_key_jwt": аутентификация на основе цифровой подписи;
- "tls_client_auth": аутентификация с использованием MTLS и PKI для связывания сертификата с клиентом.
8. Должен требовать, чтобы параметр <aud> в объекте запроса содержал URL идентификатора эмитента.
9. Не должен поддерживать публичных клиентов.
10. Должен требовать, чтобы объект запроса содержал параметр <nbf>, который не должен быть старше 60 минут.
7.2.2. ID токен в качестве отделенной подписи
Кроме того, если используется значение <response_type> = "code id_token", сервер авторизации:
1. Должен поддерживать OpenID Connect в объеме методических рекомендаций [5].
2. Должен поддерживать подписанные ID токены.
3. Должен поддерживать подписанные и зашифрованные ID токены.
4. Должен возвращать ID токен в качестве отделенной подписи (detached signature) к ответу авторизации.
Примечание. ID токен не только подтверждает идентификацию владельца ресурса (субъекта), он также идентифицирует сервер авторизации (содержит идентификатор эмитента). В случае если ID токен включает идентификатор субъекта, он действует как отделенная подпись (detached signature) источника данных к ответу авторизации. Таким образом, ID токен также защищает ответ авторизации путем включения в ID токен хэш-кода незащищенных параметров ответа <code> и <state>.
5. Если клиент предоставил значение <state>, для его защиты должен включать в ID токен хэш-код состояния <s_hash>. <s_hash> может быть опущен в ID токене, возвращаемом с конечной точки токена, если <s_hash> присутствует в ID токене, возвращаемом с конечной точки авторизации.
6. Не должен возвращать конфиденциальные персональные данные в ID токене в ответе авторизации.
Примечание. Сервер авторизации может вернуть из конечной точки авторизации больше параметров в составе ID токена, чем в ответе авторизации, согласно синтаксису OAuth 2.0.
7.2.3. JARM
Кроме того, если значение <response_type> = "code" используется в сочетании со значением <response_mode> = "jwt", сервер авторизации должен создавать защищенные JWT ответы авторизации (пункт 5.4.5).
