Как поделиться открытым ключом для проверки OAuth2 JWT?
Я реализую приложение, которое подключается к серверу OAuth2 и возвращает Json Web Token (JWT). Я передаю токен и хочу независимо проверить, что токен получен из источника выдачи.
Я могу сделать это, без проблем, с открытым ключом из источника выдачи. У меня есть это доступно мне сейчас. Все работает.
Но что если сервер OAuth изменит ключ подписи? Как проверяющее приложение получает новый ключ? Существует ли соглашение о "наилучшей практике" для совместного использования открытого ключа с сервера OAuth2? Мы только выставляем это от конечной точки на сервере аутентификации?
1 ответ
На сегодняшний день нет решения, стандартизированного как часть набора протоколов OAuth 2.0.
Считалось, что это проблема с одним доменом, которая может быть решена различными способами, которые считаются выходящими за рамки основных спецификаций OAuth (во многом аналогично тому, как API между Resource Server и Authorization Server есть / был), и так же, как и любой другой. Механизм на основе PKI в целом работает сегодня.
Но OpenID Connect - это междоменный протокол SSO, который был построен на основе OAuth 2.0, который также определил более стандартизированный вариант работы с распределением ключей в виде URI-адресов JWK как части Discover, см. jwks_uri запись в:
ТРЕБУЕТСЯ. URL-адрес документа OP JSON Web Key Set документа [JWK]. Он содержит ключ (ы) подписи, который RP использует для проверки подписей из OP. Набор JWK МОЖЕТ также содержать ключи шифрования Сервера, которые используются RP для шифрования запросов к Серверу. Когда ключи подписи и шифрования становятся доступными, значение параметра использования (Key Use) ОБЯЗАТЕЛЬНО требуется для всех ключей в указанном наборе JWK, чтобы указать предполагаемое использование каждого ключа. Хотя некоторые алгоритмы допускают использование одного и того же ключа как для подписи, так и для шифрования, это НЕ РЕКОМЕНДУЕТСЯ, поскольку это менее безопасно. Параметр JWK x5c МОЖЕТ использоваться для предоставления представленных ключей в X.509. При использовании значения открытого ключа ДОЛЖНЫ присутствовать и ДОЛЖНЫ совпадать со значениями в сертификате.
Это позволит раскрыть материал ключа по защищенному каналу HTTP, эффективно используя SSL CA для публикации и переноса материала ключа подписи JWT.
В какой-то момент jwks_uri определение может также быть частью стандартизированных расширений протокола OAuth 2.0, но сейчас вам придется полагаться на пользовательское соглашение между клиентом и сервером авторизации для этого. Это не может быть слишком сложно, чтобы реализовать себя, хотя.
Вам может повезти, если ваш Сервер авторизации также является поставщиком OpenID Connect и использует тот же материал ключа для подписи токенов ID, а также токенов доступа JWT.