Как открыть общий ключ для проверки подлинности OAuth2 JWT?

Question

Я реализую приложение, которое подключается к серверу OAuth2 и получает обратно Json Web Token (JWT). Я передаю токен, и я хочу самостоятельно подтвердить, что токен пришел из источника выдачи.

Я могу сделать это, без проблем, с открытым ключом из источника выдачи. На данный момент у меня есть это для меня. Все работает.

А что, если сервер OAuth изменит ключ подписи? Как приложение для проверки достоверности получает новый ключ? Существует ли соглашение «наилучшей практики» для совместного использования открытого ключа с сервера OAuth2? Мы просто выставляем его с конечной точки на сервере auth?

Answer 1

Нет решения, стандартизованного как часть пакета протокола OAuth 2.0 (сегодня).

Было рассмотрено, что это проблема с одним доменом, которая будет решена различными способами, которые считаются недоступными для основных спецификаций OAuth (так же, как API между сервером ресурсов и сервером авторизации есть/было) и очень похоже на любой механизм, основанный на PKI, в целом работает сегодня.

Но OpenID Connect является междоменным протоколом SSO, который был построен поверх OAuth 2.0, который также определил более стандартизованный вариант работы с распределением ключей в виде URI JWKs как части Discover, см. jwks_uri запись по адресу:

ТРЕБУЕТСЯ. URL-адрес документа JSON Web Key Set [JWK]. Этот содержит ключ (ы) подписи, используемый RP для проверки подписей от OP. Набор JWK MAY также содержит ключи (ключи) шифрования сервера, , которые используются RP для шифрования запросов на Сервер. Когда доступны ключи и ключи шифрования , значение параметра использования ключа (Key Use) НЕОБХОДИМО для всех ключей в указанном JWK. Установите значение , указывая предполагаемое использование каждого ключа. Хотя некоторые алгоритмы позволяют использовать тот же ключ для обеих подписей и шифрования, это так: НЕ РЕКОМЕНДУЕТСЯ, так как он менее безопасен. Параметр JWK x5c МОЖЕТ быть , используемый для предоставления представлений X.509 предоставленных ключей. При использовании значения незанятых ключей ДОЛЖНЫ все еще присутствовать и ДОЛЖНЫ соответствовать таковым в сертификате .

Это предоставит ключевой материал через защищенный канал HTTP, эффективно используя SSL CA для публикации и опрокидывания материала подписи JWT.

В какой-то момент определение jwks_uri может быть частью стандартизованных расширений протокола OAuth 2.0, но на данный момент вам придется полагаться на пользовательское соглашение между клиентом и сервером авторизации для этого. Однако это может быть не слишком сложно реализовать.

Возможно, вам повезет, если ваш сервер авторизации также является провайдером OpenID Connect и использует тот же ключевой материал для подписи идентификационных токенов, а также токенов доступа JWT.