Вопрос или проблема
Я работаю с клиентом, который для использования своего веб-API OAuth 2.0 требует, чтобы я предоставил им JSON Web Key (JWK), содержащий встроенный сертификат X.509. Затем, когда я запрашиваю информацию из API, они говорят, что мне нужно передать “подписанный (закрытыми ключами) JWT Bearer токен” в каждом запросе.
Я никогда не работал с JWK ранее, поэтому изучал официальную документацию JWK, но она очень плотная и не совсем объясняет, как это используется в реальных приложениях.
Я нашел этот сайт / инструмент командной строки, который может генерировать JWK в различных форматах и генерирует JWK с самоподписанным сертификатом X.509. Я думаю, в этом случае можно ли использовать самоподписанный сертификат для общения с этим API? Я понимаю, что в веб-браузерах вам абсолютно необходим сертификат от доверенного центра сертификации, так как клиент и веб-сервер по сути являются незнакомцами, но этот сертификат не используется публично для веб-сайта; он просто используется между моим приложением и этим OAuth API, и обе стороны уже доверяют друг другу.
Таким образом, на самом деле, мой вопрос заключается в том, будет ли достаточно сгенерировать JWK с самоподписанным сертификатом X.509, а затем использовать закрытый ключ сертификата для подписи JWT Bearer токенов при фактическом использовании API?
Возможное использование самоподписанного сертификата должно быть частью политики безопасности вашего клиента и/или руководящих принципов безопасности. Я бы настоятельно не рекомендовал использовать самоподписанные сертификаты в любых производственных сетях для любых целей, так как они обеспечивают меньшую безопасность, чем сертификаты, подписанные доверенным центром сертификации.
Чтобы ответить на ваш вопрос, сертификат обеспечит необходимую функциональность, но я сомневаюсь, что это ваше решение, можно ли его использовать. Вам следует проконсультироваться с вашим клиентом.
Похоже, они используют OAuth mTLS. С помощью OAuth mTLS можно достичь двух различных целей:
- Аутентификация клиента
- Токены доступа, привязанные к сертификату клиента
Обе цели могут быть достигнуты с помощью самоподписанных сертификатов, см. раздел 2.2. RFC OAuth mTLS.
Исходя из описанного вами варианта использования:
- Вам нужно передавать “подписанный (закрытыми ключами) JWT Bearer токен” в каждом запросе.
- (Я предполагаю,) что RSA публичный ключ, который подписывает этот JWT, должен быть в сертификате X.509. Таким образом, ваша структура данных будет выглядеть как:
JWK{ X.509Cert{ RSAPubKey } } --signs--> JWT
Очевидно, что сервер не хочет принимать JWT, подписанные любым ключом, поэтому ему нужен способ установить доверие к RSAPubKey.
Существует два основных подхода:
- PKI: сертификат X.509 выдан центром сертификации, которому доверяет сервер.
- Самоподписанный и зарегистрированный: здесь будет какой-то явный шаг регистрации, где клиент говорит: “Вот RSA ключ, который я буду использовать для подписания своих будущих запросов”, и сервер поддерживает список таких клиентских ключей.
Оба подхода приемлемы. В случае PKI центр сертификации выполняет всю тяжелую работу по обеспечению соответствия информации о названии в сертификате информации о аккаунте пользователя. В случае самоподписанного сертификата пользователь сам выбирает метаданные сертификата, поэтому вашему серверу нужно провести больше проверок во время процесса регистрации и внимательно относиться к привязке сертификатов / публичных ключей к аккаунтам, но в этом подходе нет ничего принципиально неправильного.
Ответ или решение
Использование самоподписанного сертификата X.509 в JWK для API OAuth 2.0
Работа с OAuth 2.0 и использованием JSON Web Key (JWK) с X.509 сертификатом может быть сложной задачей, особенно когда речь идет о самоподписанных сертификатах. В данном контексте становится критически важным понять, насколько безопасно использование самоподписанных сертификатов, и как они могут быть применены для взаимодействия с API.
Природа самоподписанных сертификатов
Самоподписанные сертификаты создаются и подписываются тем же лицом или организацией, которая их использует. Это отличается от сертификатов, выданных центром сертификации (CA), где третья сторона подтверждает идентичность владельца сертификата. Самоподписанные сертификаты могут быть полезными в закрытых системах или для внутренних целей, где контролируется каждое соединение, и обе стороны доверяют друг другу.
Безопасность и соответствие требованиям
Предоставление самоподписанного сертификата для подключения к API может быть допустимо, если обе стороны (клиент и сервер) согласны на этот подход. Однако использование самоподписанных сертификатов в производственной среде имеет свои риски. В частности, ни один сторонний проверяющий орган не гарантирует достоверность информации о владельце сертификата, что потенциально может привести к проблемам безопасности. Поэтому решение об использовании такого подхода должно быть согласовано с клиентом и включать в себя детали политик безопасности.
Общая структура взаимодействия
Когда вы используете JWK с встроенным X.509 сертификатом для получения токена JWT, ваша схема может выглядеть следующим образом:
JWK{ X.509Cert{ RSAPubKey } } --signs--> JWTВ этом контексте важно понимать, что сервер API должен быть способен управлять доверием к определенным ключам. Это может быть достигнуто следующими способами:
-
Использование инфраструктуры открытых ключей (PKI): Здесь X.509 сертификат выдается проверенным CA, и сервер API доверяет этому CA.
-
Явная регистрация самоподписанных сертификатов: Клиент должен будет пройти процесс регистрации, предоставляя публичный ключ, который он будет использовать для подписания запросов. Сервер затем должен вести список всех таких ключей, чтобы обеспечить безопасность.
Рекомендации по выбору сертификата
Прежде чем принимать решение о использовании самоподписанного сертификата:
- Проверьте, согласен ли ваш клиент на использование самоподписанных сертификатов и изучите их политику безопасности.
- Убедитесь, что предусмотрен процесс регистрации для проверки публичных ключей.
- Оцените возможность использования публично удостоверенных сертификатов, если это возможно. Они обеспечивают более высокий уровень доверия и безопасности, что может быть критически важно для вашего приложения.
Заключение
Использование самоподписанного X.509 сертификата в JWK для API OAuth 2.0 может быть допустимо, но требует тщательного рассмотрения со стороны всех участников процесса. Убедитесь, что ваша реализация соответствует требованиям безопасности и что все стороны доверяют выбранному подходу. В конечном счете, главное — это строить безопасные и надежные соединения, которые удовлетворяют потребности всех участников.