5.8.4. Токен доступа, связанный с MTLS-сертификатом клиента

5.8.4.1. Если клиент использует взаимную аутентификацию по протоколу TLS при подключении к конечной точке токена, сервер авторизации может связать выданный токен доступа с предъявленным сертификатом клиента. Такое связывание достигается путем встраивания хэш-кода сертификата в выданный токен доступа с использованием JWT-синтаксиса (см. подпункт 5.8.4.2) или посредством интроспекции токена (запроса информации о токене) у сервера авторизации (см. подпункт 5.8.4.3). Эта привязка может выполняться как совместно с аутентификацией клиента по сертификату MTLS (см. пункты 5.5.4 и 5.5.5), так и отдельно от аутентификации клиента сервером авторизации, что позволяет MTLS во время защищенного доступа к ресурсам служить исключительно механизмом подтверждения владения закрытым ключом.

Чтобы сервер ресурсов мог использовать токены доступа с привязкой к сертификату, он должен заранее знать, что для обращения к защищенным ресурсам должен использоваться MTLS. В частности, сам токен доступа не может использоваться в качестве входных данных для принятия решения о том, запрашивать или нет установление MTLS-соединения.

В процессе доступа к ресурсам, защищенным протоколом TLS с взаимной аутентификацией сторон, клиент может выполнять запросы к защищенным ресурсам, как описано в подразделе 5.6, однако эти запросы должны быть выполнены по аутентифицированному MTLS-соединению, используя тот же сертификат, который использовался для MTLS-соединения в конечной точке токена при запросе токена доступа.

Сервер ресурсов должен получить TLS-сертификат клиента, используемый для установления взаимно аутентифицированного TLS-соединения, должен проверить, что сертификат соответствует сертификату, связанному с предъявленным токеном доступа. Если они не совпадают, попытка доступа к ресурсу должна быть отклонена со статусом HTTP 401 и кодом ошибки "invalid_token".

Метаданные, необходимые для того, чтобы сервер и клиент сигнализировали о желании использовать токены доступа с привязкой к MTLS-сертификату клиента, определены в подпункте 5.8.4.4.

5.8.4.2. Метод подтверждения отпечатка сертификата с использованием JWT

Чтобы представить хэш-код Х.509 сертификата в формате JWT (5.7), в качестве значения параметра токена <cnf> используется строка, идентифицирующая метод подтверждения на основе хэш-функции с длиной образа не менее 256 битов, и значение хэш-кода, которое формируется как Base64url кодирование значения хэш-функции, вычисленное от DER-представления (по ГОСТ Р ИСО/МЭК 8825-1) сертификата формата Х.509.

Примечание. Дополнительные сведения о методе подтверждения отпечатка сертификата с использованием JWT приведены в [39] (подраздел 3.1).

Ниже приведен пример функционального содержимого JWT, содержащего подтверждение отпечатка сертификата.

5.8.4.3. Метод подтверждения отпечатка сертификата с использованием интроспекции токена

Интроспекция токена OAuth 2.0 определяет способ, с помощью которого сервер ресурсов может запрашивать у сервера авторизации информацию о состоянии активности токена доступа, а также другую метаинформацию о токене доступа.

Для токена доступа, связанного с сертификатом MTLS, хэш-код сертификата, с которым связан токен, передается серверу защищенного ресурса в виде метаинформации в составе ответа интроспекции токена. Хэш-код передается с использованием того же параметра <cnf> с элементом, идентифицирующим метод подтверждения на основе хэш-функции, что и при использовании метода подтверждения отпечатка сертификата, описанного в подпункте 5.8.4.2, в качестве параметра верхнего уровня JSON-ответа интроспекции. Сервер ресурсов сравнивает полученный таким образом хэш-код сертификата со значением хэш-кода, вычисленного на основе сертификата клиента, использованного для взаимной аутентификации сеанса TLS, и отклоняет запрос, если они не совпадают.

Примечания

1 Дополнительные сведения о протоколе интроспекции токена доступа представлены в RFC 7662 [38].

2 Дополнительные сведения о методе подтверждения отпечатка сертификата с использованием интроспекции токена приведены в [39] (подраздел 3.1).

Ниже приведен пример ответа интроспекции для активного токена с подтверждением отпечатка сертификата.

5.8.4.4. Метаданные сервера авторизации и клиента для подтверждения отпечатка MTLS-сертификата

Следующий параметр метаданных сервера авторизации, публикуемый в соответствии с требованиями подпункта 5.4.4.1, указывает на способность сервера авторизации выдавать токены доступа с привязкой к сертификату:

- <tls_client_certificate_bound_access_tokens>: (опциональный) логическое значение, указывающее на поддержку сервером токенов доступа с привязкой к MTLS-сертификату клиента. Значением по умолчанию является "false".

Следующий параметр метаданных клиента, публикуемый в соответствии с требованиями подпункта 5.4.4.5, позволяет сигнализировать о намерении клиента использовать токены доступа с привязкой к сертификату:

- <tls_client_certificate_bound_access_tokens>: (опциональный) логическое значение, используемое для указания намерения клиента использовать токены доступа, привязанные к MTLS-сертификату клиента. Значением по умолчанию является "false".

Если клиент, который указал намерение использовать токены, привязанные к MTLS-сертификату клиента, отправляет запрос на конечную точку токена по соединению, не являющемуся MTLS, на усмотрение сервера авторизации остается принятие решения относительно того, следует ли возвращать ошибку или выдать токен, не связанный с сертификатом.