6.2. Положения об обеспечении безопасности сервера авторизации

6.2.1. Сервер(у) авторизации:

1. Должен поддерживать конфиденциальных клиентов.

2. Не должен поддерживать публичных клиентов.

3. В случае использования симметричного ключа должен предоставлять секрет клиента <client_secret>, соответствующий требованиям пункта 5.8.2.

4. Должен аутентифицировать конфиденциального клиента в конечной точке токена, используя один из следующих методов (подраздел 5.5):

- client_secret_jwt: аутентификация на основе кода аутентификации HMAC и <client_secret>;

- private_key_jwt: аутентификация на основе цифровой подписи;

- tls_client_auth: аутентификация с использованием MTLS и PKI для связывания сертификата с клиентом.

5. Должен требовать и использовать ключ, размер которого составляет 256 бит или больше для симметричных алгоритмов и алгоритмов на основе эллиптической кривой ([5]).

6. Должен требовать использования технологии PKCE (подпункт 5.4.2.4) со значением "St256" (пункт 6.2.6 [5]) в качестве метода запроса кода.

7. Должен требовать предварительной регистрации URI-переадресации клиентов.

8. Должен требовать наличия параметра <redirect_URI> в запросе аутентификации (подпункт 5.4.2.2).

9. Должен требовать, чтобы значение параметра <redirect_URI> точно соответствовало одному из предварительно зарегистрированных URI-переадресации клиента (подпункт 5.4.4.3).

10. Должен требовать аутентификацию конечного пользователя на соответствующем уровне гарантии ([6]) для операций, которые клиент будет уполномочен выполнять от имени пользователя; допустимые контексты аутентификации пользователя сервер авторизации получает в качестве значения <acr_values> запроса аутентификации.

11. Должен требовать явного согласия конечного пользователя на авторизацию доступа к запрашиваемой области действия (параметр <scope>), если она не была ранее авторизована.

12. Должен исключать повторное использование кодов авторизации в соответствии с подпунктом 5.4.2.11.

13. Должен возвращать ответ на запрос токена доступа в соответствии с подпунктом 5.4.2.9.

14. Должен возвращать список предоставленных областей действия (параметр <scope>) по выданному токену доступа (подпункт 5.4.2.15).

15. Должен предоставлять непредсказуемые токены доступа, коды авторизации и токены обновления (если необходимо) с достаточной энтропией, чтобы вероятность того, что злоумышленник угадает сгенерированный токен, была вычислительно неосуществима, согласно требованиям пункта 10.1.3 [5].

16. Рекомендуется точно определять детали предоставления конечному пользователю прав во время авторизации в соответствии с подразделом 16.18 [17].

17. Рекомендуется предоставлять конечному пользователю механизм аннулирования токенов доступа и токенов обновления, выданных клиенту.

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

19. Должен требовать, чтобы сервисы по адресу URI-переадресации использовали протокол HTTPS.

20. Рекомендуется выдавать токены доступа со сроком действия менее 10 минут, если только токены не ограничены отправителем.

21. Должен поддерживать OpenID Discovery [40], может поддерживать метаданные сервера авторизации в соответствии с RFC8414 [41] и не должен распространять метаданные обнаружения (такие как конечная точка авторизации) любым другим способом.

Примечания:

1. Рекомендуется использовать токены обновления вместо токенов доступа с длительным сроком действия.

2. Сервер может ограничивать область действия <scope>, чтобы не реализовывать определенные API.

3. Ожидается, что клиенты будут рассматривать токены доступа как неструктурированные, непрозрачные символьные строки.

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

6.2.2. При обработке параметра <scope> в запросе аутентификации сервер авторизации:

1. Должен требовать обязательного наличия непустого значения параметра <scope> в запросе аутентификации.

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

3. Не должен предполагать значений <scope> по умолчанию.

4. Должен игнорировать неизвестные или неразрешенные значения <scope>.

5. Должен выдать токен доступа, перечислив в явном виде только разрешенные клиенту области действия, если доступ клиента хотя бы к одному значению из перечня <scope> разрешен.

6. Должен вернуть сообщение об ошибке, если в перечне <scope> нет известных или разрешенных клиенту значений.

6.2.3. Если в ответе на запрос токена доступа возвращается идентификатор аутентифицированного пользователя, сервер авторизации:

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

2. Должен осуществлять проверку запроса аутентификации (пункт 6.2.7 [5]).

3. Должен аутентифицировать пользователя в соответствии с подпунктом 5.4.2.5.

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

5. Должен осуществлять проверку запроса токена в соответствии с подпунктом 5.4.2.11.

6. Если параметр <scope> запроса аутентификации включает "openid", должен генерировать ID токен в составе ответа на запрос токена в соответствии с подпунктом 5.4.2.12 со значением параметра <sub>, соответствующим аутентифицированному пользователю, и значением <acr> в составе ID токена, указывающим на класс аутентификации в соответствии с [6].

6.2.4. Если клиент запрашивает область действия "openid", сервер авторизации должен требовать наличия в запросе аутентификации значения параметра <nonce> (подпункт 5.4.2.2).