Обзор политик JWS и JWT

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee X.info

В этом разделе представлена ​​общая информация о JWT (JSON Web Token) и JWS (JSON Web Signature), а также о политиках Apigee JWS/JWT, которая может представлять интерес для разработчиков прокси-серверов Apigee.

Введение

И JWS, и JWT широко используются для обмена утверждениями или заявлениями между подключенными приложениями. Политики JWS/JWT позволяют прокси-серверам Edge API:

  • Сгенерируйте подписанный JWT или JWS .
  • Проверьте подписанный JWT или JWS и заявления, содержащиеся в JWS/JWT.
  • Расшифровать подписанный JWT или JWS без проверки подписи.

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

При использовании политики «Проверка JWS/JWT» недействительный JWS/JWT будет отклонен, что приведет к ошибке. Аналогично, при использовании политики «Декодирование JWS/JWT» некорректный JWS/JWT также приведет к ошибке.

Видео

Посмотрите короткое видео, чтобы быстро ознакомиться с JWT. Хотя это видео посвящено именно созданию JWT, многие из рассматриваемых концепций применимы и к JWS.

Это короткое видео позволит вам узнать больше о структуре JWT.

Варианты использования

Политики JWS/JWT можно использовать для:

  • Создайте новый JWS/JWT либо на стороне прокси-сервера, либо на стороне целевой конечной точки пограничного прокси-сервера. Например, вы можете создать поток запросов прокси-сервера, который генерирует JWS/JWT и возвращает его клиенту. Или вы можете настроить прокси-сервер таким образом, чтобы он генерировал JWS/JWT в потоке запросов целевой точки и прикреплял его к запросу, отправленному на целевую точку. Затем эти утверждения будут доступны для того, чтобы бэкэнд-сервисы могли применять дальнейшую обработку безопасности.
  • Проверка и извлечение утверждений из JWS/JWT, полученных из входящих запросов клиентов, ответов целевых служб, ответов политик вызовов служб или из других источников. Edge проверит подпись JWS/JWT, независимо от того, был ли JWS/JWT сгенерирован третьей стороной или самой Edge, используя алгоритмы RSA или HMAC.
  • Расшифровка JWS/JWT. Расшифровка наиболее полезна при использовании совместно с политикой проверки JWS/JWT, когда значение утверждения (JWT) или заголовка (JWS/JWT) внутри JWS/JWT должно быть известно до проверки JWS/JWT.

Части JWS/JWT

Подписанный JWS/JWT кодирует информацию в трех частях, разделенных точками: заголовок, полезная нагрузка и подпись.

header.payload.signature
  • Политика Generate JWS/JWT создает все три части.
  • Политика проверки JWS/JWT рассматривает все три части.
  • Политика декодирования JWS/JWT проверяет только заголовок и полезную нагрузку.

JWS также поддерживает отсоединенный формат, в котором полезная нагрузка из JWS отсутствует:

header..signature

При использовании отсоединенного JWS полезная нагрузка отправляется отдельно от JWS. Для указания необработанной, незакодированной полезной нагрузки JWS используется элемент <DetachedContent> политики проверки JWS. Затем политика проверки JWS проверяет JWS, используя заголовок и подпись в JWS, а также полезную нагрузку, указанную элементом <DetachedContent> .

Чтобы узнать больше о токенах, а также о том, как они кодируются и подписываются, см.:

Различия между JWS и JWT

Для обмена утверждениями или заявлениями между подключенными приложениями можно использовать либо JWT, либо JWS. Основное различие между ними заключается в способе представления полезной нагрузки:

  • JWT
    • Полезная нагрузка всегда представляет собой объект JSON.
    • Полезная нагрузка всегда прикреплена к JWT.
    • В заголовке typ токена всегда устанавливается значение JWT
  • JWS
    • Полезная нагрузка может быть представлена ​​в любом формате, например, в виде объекта JSON, потока байтов, потока октетов и других.
    • Полезную нагрузку не обязательно прикреплять к JWS.

Поскольку формат JWT всегда использует объект JSON для представления полезной нагрузки, политики Edge Generate JWT и Verify JWT имеют встроенную поддержку для обработки распространенных зарегистрированных имен утверждений, таких как aud , iss , sub и другие. Это означает, что вы можете использовать элементы политики Generate JWT для установки этих утверждений в полезной нагрузке, а элементы политики Verify JWT — для проверки их значений. Дополнительную информацию см. в разделе «Зарегистрированные имена утверждений» спецификации JWT.

Помимо поддержки определенных зарегистрированных имен утверждений, политика генерации JWT напрямую поддерживает добавление в JWT утверждений с произвольными именами. Каждое утверждение представляет собой простую пару «имя/значение», где значение может быть типа число, логическое значение, строка, карта или массив.

Поскольку JWS может использовать любое представление данных для полезной нагрузки, вы не можете добавлять утверждения в полезную нагрузку. Политика Generate JWS поддерживает добавление утверждений с произвольными именами в заголовок JWS. Кроме того, политики JWS поддерживают отдельную полезную нагрузку, когда JWS не содержит полезной нагрузки. Отдельная полезная нагрузка позволяет отправлять JWS и полезную нагрузку отдельно и требуется в соответствии с рядом стандартов безопасности.

Предотвращение внедрения шаблона при использовании JWS и JWT

Чтобы предотвратить несанкционированное разглашение данных, следуйте этим рекомендациям при использовании политик GenerateJWT или GenerateJWS:

  • Избегайте прямых ссылок на пользовательский ввод: никогда не используйте ненадежные входные данные (например, request.queryparam.* или request.header.* ) напрямую в атрибуте ref , поддерживающем шаблонизацию.
  • Очистка входных данных: Если вам необходимо использовать внешние данные в утверждении JWT/JWS, сначала используйте политику AssignMessage для удаления фигурных скобок ( { } ) или других символов шаблона из входных данных перед тем, как ссылаться на них.
  • Используйте явные утверждения для строк: для простых строковых утверждений избегайте использования type="map" . Использование type="string" по умолчанию предотвращает неявное шаблонирование ссылочного значения.
  • Обратите внимание на несоответствие в поведении политик проверки и генерации: политики генерации JWS и JWT ведут себя иначе, чем политики проверки, в отношении шаблонизации.

Об алгоритмах подписи

Политики проверки и генерации JWS/JWT поддерживают алгоритмы RSA, RSASSA-PSS, ECDSA и HMAC, используя контрольные суммы SHA2 с битовой стойкостью 256, 384 или 512. Политика декодирования JWS/JWT работает независимо от алгоритма, использованного для подписи JWS/JWT.

алгоритм HMAC

Алгоритм HMAC основан на использовании общего секрета, известного как секретный ключ, для создания подписи (также известной как подписание JWS/JWT) и для проверки подписи.

Минимальная длина секретного ключа зависит от битовой стойкости алгоритма:

  • HS256: минимальная длина ключа 32 байта.
  • HS386: минимальная длина ключа 48 байт.
  • HS512: минимальная длина ключа 64 байта.

алгоритм RSA

Алгоритм RSA использует пару открытого и закрытого ключей для криптографической подписи. При использовании подписей RSA подписывающая сторона использует закрытый ключ RSA для подписи JWS/JWT, а проверяющая сторона использует соответствующий открытый ключ RSA для проверки подписи JWS/JWT. Ограничений по размеру ключей нет.

алгоритм RSASSA-PSS

Алгоритм RSASSA-PSS является обновленной версией алгоритма RSA. Как и RSS, RSASSA-PSS использует пару открытого/закрытого ключей RSA для криптографической подписи. Формат ключа такой же, как и для RSS. Подписывающая сторона использует закрытый ключ для подписи JWS/JWT, а проверяющая сторона использует соответствующий открытый ключ для проверки подписи JWS/JWT. Ограничений по размеру ключей нет.

алгоритм ECDSA

Алгоритм цифровой подписи на эллиптических кривых (ECDSA) — это алгоритм криптографии на эллиптических кривых с кривыми P-256, P-384 и P-521. При использовании алгоритма ECDSA определяется тип открытого и закрытого ключа, который необходимо указать:

Алгоритм Изгиб Ключевое требование
ES256 П-256 Ключ, сгенерированный на основе кривой P-256 (также известной как secp256r1 или prime256v1).
ES384 П-384 Ключ, сгенерированный на основе кривой P-384 (также известной как secp384r1).
ES512 П-521 Ключ, сгенерированный на основе кривой P-521 (также известной как secp521r1).

Алгоритмы шифрования ключей

Политики JWS/JWT поддерживают все алгоритмы шифрования ключей, поддерживаемые OpenSSL .

Использование набора веб-ключей JSON (JWKS) для проверки JWS/JWT

При проверке подписанного JWS/JWT необходимо предоставить открытый ключ, связанный с закрытым ключом, использованным для подписи токена. Для проверки JWS/JWT можно использовать два варианта предоставления открытого ключа:

  • использовать фактическое значение открытого ключа (обычно предоставляемое в переменной потока) или
  • Используйте открытый ключ, заключенный в JWKS-файл.

О JWKS

JWKS — это структура JSON, представляющая набор веб-ключей JSON (JWK). JWK — это структура данных JSON, представляющая криптографический ключ. JWK и JWKS описаны в RFC7517 . Примеры JKWS см. в Приложении A. Примеры наборов веб-ключей JSON.

Структура JWKS

В RFC7517 описаны ключевые элементы JWKS для каждого типа ключа, например, "RSA" или "EC". Например, в зависимости от типа ключа эти параметры могут включать:

  • kty - Тип ключа, например, "RSA" или "EC".
  • kid (идентификатор ключа) — может принимать любое произвольное значение (без дубликатов в наборе ключей). Если входящий JWT имеет идентификатор ключа, присутствующий в наборе JWKS, то политика будет использовать правильный открытый ключ для проверки подписи JWS/JWT.

Ниже приведены примеры необязательных элементов и их значений:

  • alg — ключевой алгоритм. Он должен совпадать с алгоритмом подписи в JWS/JWT.
  • использование - Если присутствует, должно быть sig.

Приведенный ниже JWKS-файл содержит необходимые элементы и значения и будет действителен в Edge (из https://www.googleapis.com/oauth2/v3/certs ):

{
   "keys":[
      {
         "kty":"RSA",
         "alg":"RS256",
         "use":"sig",
         "kid":"ca04df587b5a7cead80abee9ea8dcf7586a78e01",
         "n":"iXn-WmrwLLBa-QDiToBozpu4Y4ThKdwORWFXQa9I75pKOvPUjUjE2Bk05TUSt7-V7KDjCq0_Nkd-X9rMRV5LKgCa0_F8YgI30QS3bUm9orFryrdOc65PUIVFVxIwMZuGDY1hj6HEJVWIr0CZdcgNIll06BasclckkUK4O-Eh7MaQrqb646ghFlG3zlgk9b2duHbDOq3s39ICPinRQWC6NqTYfqg7E8GN_NLY9srUCc_MswuUfMJ2cKT6edrhLuIwIj_74YGkpOwilr2VswKsvJ7dcoiJxheKYvKDKtZFkbKrWETTJSGX2Xeh0DFB0lqbKLVvqkM2lFU2Qx1OgtTnrw",
         "e":"AQAB"
      },
      {
          "kty":"EC",
          "alg":"ES256",
          "use":"enc",
          "kid":"k05TUSt7-V7KDjCq0_N"
          "crv":"P-256",
          "x":"Xej56MungXuFZwmk_xccvsMpCtXmqhvEEMCmHyAmKF0",
          "y":"Bozpu4Y4ThKdwORWFXQa9I75pKOvPUjUjE2Bk05TUSt",
      }
   ]
}

Разработка прокси-сервера для использования JWKS

Когда JWS/JWT получают от эмитента, часто эмитент вставляет в заголовок JWS/JWT идентификатор ключа (или kid). Этот ключ сообщает получателю JWS/JWT, как найти открытый или секретный ключ, необходимый для проверки подписи подписанного JWS/JWT.

В качестве примера предположим, что эмитент подписывает JWT закрытым ключом. "Идентификатор ключа" определяет соответствующий открытый ключ, используемый для проверки JWT. Список открытых ключей обычно доступен по какой-либо известной конечной точке, например: https://www.googleapis.com/oauth2/v3/certs .

Это основная последовательность действий, которую Edge (или любая другая платформа, работающая с JWKS) должна выполнить для работы с JWS/JWT, содержащим JWKS-файл:

  1. Изучите заголовок JWS/JWT, чтобы найти идентификатор ключа (kid).
  2. Изучите заголовок JWS/JWT, чтобы найти алгоритм подписи (alg), например, RS256.
  3. Получите список ключей и идентификаторов из JWKS-файла известной конечной точки для заданного эмитента.
  4. Извлеките открытый ключ из списка ключей, используя идентификатор ключа, указанный в заголовке JWS/JWT, и соответствующий алгоритм, если алгоритм указан в ключе JWKS.
  5. Используйте этот открытый ключ для проверки подписи JWS/JWT.

Разработчику прокси-серверов Edge API необходимо выполнить следующие действия для проверки JWS/JWT:

  1. Получите список ключей и идентификаторов из общеизвестной конечной точки для заданного эмитента. Для этого шага можно использовать политику вызова сервиса.
  2. В политике проверки JWS/JWT укажите местоположение JWS/JWT в элементе <Source> , а полезную нагрузку JWKS — в элементе <PublicKey/JWKS> . Например, для политики проверки JWT: 
    <VerifyJWT name="JWT-Verify-RS256">
    <Algorithm>RS256</Algorithm>
    <Source>json.jwt</Source>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <PublicKey>
        <JWKS ref="public.jwks"/>
    </PublicKey>
    <Subject>apigee-seattle-hatrack-montage</Subject>
    <Issuer>urn://apigee-edge-JWT-policy-test</Issuer>
    <Audience>urn://c60511c0-12a2-473c-80fd-42528eb65a6a</Audience>
    <AdditionalClaims>
        <Claim name="show">And now for something completely different.</Claim>
    </AdditionalClaims>
</VerifyJWT>

Политика проверки JWT выполняет все остальные действия:

  • Если в JWKS не найден ключ с идентификатором, совпадающим с идентификатором ключа (kid), указанным в JWT, то политика проверки JWT выдает ошибку и не проверяет JWT.
  • Если входящий JWT не содержит идентификатор ключа (kid) в заголовке, то сопоставление keyid с verification-key невозможно.

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

,

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee X.info

В этом разделе представлена ​​общая информация о JWT (JSON Web Token) и JWS (JSON Web Signature), а также о политиках Apigee JWS/JWT, которая может представлять интерес для разработчиков прокси-серверов Apigee.

Введение

И JWS, и JWT широко используются для обмена утверждениями или заявлениями между подключенными приложениями. Политики JWS/JWT позволяют прокси-серверам Edge API:

  • Сгенерируйте подписанный JWT или JWS .
  • Проверьте подписанный JWT или JWS и заявления, содержащиеся в JWS/JWT.
  • Расшифровать подписанный JWT или JWS без проверки подписи.

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

При использовании политики «Проверка JWS/JWT» недействительный JWS/JWT будет отклонен, что приведет к ошибке. Аналогично, при использовании политики «Декодирование JWS/JWT» некорректный JWS/JWT также приведет к ошибке.

Видео

Посмотрите короткое видео, чтобы быстро ознакомиться с JWT. Хотя это видео посвящено именно созданию JWT, многие из рассматриваемых концепций применимы и к JWS.

Это короткое видео позволит вам узнать больше о структуре JWT.

Варианты использования

Политики JWS/JWT можно использовать для:

  • Создайте новый JWS/JWT либо на стороне прокси-сервера, либо на стороне целевой конечной точки пограничного прокси-сервера. Например, вы можете создать поток запросов прокси-сервера, который генерирует JWS/JWT и возвращает его клиенту. Или вы можете настроить прокси-сервер таким образом, чтобы он генерировал JWS/JWT в потоке запросов целевой точки и прикреплял его к запросу, отправленному на целевую точку. Затем эти утверждения будут доступны для того, чтобы бэкэнд-сервисы могли применять дальнейшую обработку безопасности.
  • Проверка и извлечение утверждений из JWS/JWT, полученных из входящих запросов клиентов, ответов целевых служб, ответов политик вызовов служб или из других источников. Edge проверит подпись JWS/JWT, независимо от того, был ли JWS/JWT сгенерирован третьей стороной или самой Edge, используя алгоритмы RSA или HMAC.
  • Расшифровка JWS/JWT. Расшифровка наиболее полезна при использовании совместно с политикой проверки JWS/JWT, когда значение утверждения (JWT) или заголовка (JWS/JWT) внутри JWS/JWT должно быть известно до проверки JWS/JWT.

Части JWS/JWT

Подписанный JWS/JWT кодирует информацию в трех частях, разделенных точками: заголовок, полезная нагрузка и подпись.

header.payload.signature
  • Политика Generate JWS/JWT создает все три части.
  • Политика проверки JWS/JWT рассматривает все три части.
  • Политика декодирования JWS/JWT проверяет только заголовок и полезную нагрузку.

JWS также поддерживает отсоединенный формат, в котором полезная нагрузка из JWS отсутствует:

header..signature

При использовании отсоединенного JWS полезная нагрузка отправляется отдельно от JWS. Для указания необработанной, незакодированной полезной нагрузки JWS используется элемент <DetachedContent> политики проверки JWS. Затем политика проверки JWS проверяет JWS, используя заголовок и подпись в JWS, а также полезную нагрузку, указанную элементом <DetachedContent> .

Чтобы узнать больше о токенах, а также о том, как они кодируются и подписываются, см.:

Различия между JWS и JWT

Для обмена утверждениями или заявлениями между подключенными приложениями можно использовать либо JWT, либо JWS. Основное различие между ними заключается в способе представления полезной нагрузки:

  • JWT
    • Полезная нагрузка всегда представляет собой объект JSON.
    • Полезная нагрузка всегда прикреплена к JWT.
    • В заголовке typ токена всегда устанавливается значение JWT
  • JWS
    • Полезная нагрузка может быть представлена ​​в любом формате, например, в виде объекта JSON, потока байтов, потока октетов и других.
    • Полезную нагрузку не обязательно прикреплять к JWS.

Поскольку формат JWT всегда использует объект JSON для представления полезной нагрузки, политики Edge Generate JWT и Verify JWT имеют встроенную поддержку для обработки распространенных зарегистрированных имен утверждений, таких как aud , iss , sub и другие. Это означает, что вы можете использовать элементы политики Generate JWT для установки этих утверждений в полезной нагрузке, а элементы политики Verify JWT — для проверки их значений. Дополнительную информацию см. в разделе «Зарегистрированные имена утверждений» спецификации JWT.

Помимо поддержки определенных зарегистрированных имен утверждений, политика генерации JWT напрямую поддерживает добавление в JWT утверждений с произвольными именами. Каждое утверждение представляет собой простую пару «имя/значение», где значение может быть типа число, логическое значение, строка, карта или массив.

Поскольку JWS может использовать любое представление данных для полезной нагрузки, вы не можете добавлять утверждения в полезную нагрузку. Политика Generate JWS поддерживает добавление утверждений с произвольными именами в заголовок JWS. Кроме того, политики JWS поддерживают отдельную полезную нагрузку, когда JWS не содержит полезной нагрузки. Отдельная полезная нагрузка позволяет отправлять JWS и полезную нагрузку отдельно и требуется в соответствии с рядом стандартов безопасности.

Предотвращение внедрения шаблона при использовании JWS и JWT

Чтобы предотвратить несанкционированное разглашение данных, следуйте этим рекомендациям при использовании политик GenerateJWT или GenerateJWS:

  • Избегайте прямых ссылок на пользовательский ввод: никогда не используйте ненадежные входные данные (например, request.queryparam.* или request.header.* ) напрямую в атрибуте ref , поддерживающем шаблонизацию.
  • Очистка входных данных: Если вам необходимо использовать внешние данные в утверждении JWT/JWS, сначала используйте политику AssignMessage для удаления фигурных скобок ( { } ) или других символов шаблона из входных данных перед тем, как ссылаться на них.
  • Используйте явные утверждения для строк: для простых строковых утверждений избегайте использования type="map" . Использование type="string" по умолчанию предотвращает неявное шаблонирование ссылочного значения.
  • Обратите внимание на несоответствие в поведении политик проверки и генерации: политики генерации JWS и JWT ведут себя иначе, чем политики проверки, в отношении шаблонизации.

Об алгоритмах подписи

Политики проверки и генерации JWS/JWT поддерживают алгоритмы RSA, RSASSA-PSS, ECDSA и HMAC, используя контрольные суммы SHA2 с битовой стойкостью 256, 384 или 512. Политика декодирования JWS/JWT работает независимо от алгоритма, использованного для подписи JWS/JWT.

алгоритм HMAC

Алгоритм HMAC основан на использовании общего секрета, известного как секретный ключ, для создания подписи (также известной как подписание JWS/JWT) и для проверки подписи.

Минимальная длина секретного ключа зависит от битовой стойкости алгоритма:

  • HS256: минимальная длина ключа 32 байта.
  • HS386: минимальная длина ключа 48 байт.
  • HS512: минимальная длина ключа 64 байта.

алгоритм RSA

Алгоритм RSA использует пару открытого и закрытого ключей для криптографической подписи. При использовании подписей RSA подписывающая сторона использует закрытый ключ RSA для подписи JWS/JWT, а проверяющая сторона использует соответствующий открытый ключ RSA для проверки подписи JWS/JWT. Ограничений по размеру ключей нет.

алгоритм RSASSA-PSS

Алгоритм RSASSA-PSS является обновленной версией алгоритма RSA. Как и RSS, RSASSA-PSS использует пару открытого/закрытого ключей RSA для криптографической подписи. Формат ключа такой же, как и для RSS. Подписывающая сторона использует закрытый ключ для подписи JWS/JWT, а проверяющая сторона использует соответствующий открытый ключ для проверки подписи JWS/JWT. Ограничений по размеру ключей нет.

алгоритм ECDSA

Алгоритм цифровой подписи на эллиптических кривых (ECDSA) — это алгоритм криптографии на эллиптических кривых с кривыми P-256, P-384 и P-521. При использовании алгоритма ECDSA определяется тип открытого и закрытого ключа, который необходимо указать:

Алгоритм Изгиб Ключевое требование
ES256 П-256 Ключ, сгенерированный на основе кривой P-256 (также известной как secp256r1 или prime256v1).
ES384 П-384 Ключ, сгенерированный на основе кривой P-384 (также известной как secp384r1).
ES512 П-521 Ключ, сгенерированный на основе кривой P-521 (также известной как secp521r1).

Алгоритмы шифрования ключей

Политики JWS/JWT поддерживают все алгоритмы шифрования ключей, поддерживаемые OpenSSL .

Использование набора веб-ключей JSON (JWKS) для проверки JWS/JWT

При проверке подписанного JWS/JWT необходимо предоставить открытый ключ, связанный с закрытым ключом, использованным для подписи токена. Для проверки JWS/JWT можно использовать два варианта предоставления открытого ключа:

  • использовать фактическое значение открытого ключа (обычно предоставляемое в переменной потока) или
  • Используйте открытый ключ, заключенный в JWKS-файл.

О JWKS

JWKS — это структура JSON, представляющая набор веб-ключей JSON (JWK). JWK — это структура данных JSON, представляющая криптографический ключ. JWK и JWKS описаны в RFC7517 . Примеры JKWS см. в Приложении A. Примеры наборов веб-ключей JSON.

Структура JWKS

В RFC7517 описаны ключевые элементы JWKS для каждого типа ключа, например, "RSA" или "EC". Например, в зависимости от типа ключа эти параметры могут включать:

  • kty - Тип ключа, например, "RSA" или "EC".
  • kid (идентификатор ключа) — может принимать любое произвольное значение (без дубликатов в наборе ключей). Если входящий JWT имеет идентификатор ключа, присутствующий в наборе JWKS, то политика будет использовать правильный открытый ключ для проверки подписи JWS/JWT.

Ниже приведены примеры необязательных элементов и их значений:

  • alg — ключевой алгоритм. Он должен совпадать с алгоритмом подписи в JWS/JWT.
  • использование - Если присутствует, должно быть sig.

Приведенный ниже JWKS-файл содержит необходимые элементы и значения и будет действителен в Edge (из https://www.googleapis.com/oauth2/v3/certs ):

{
   "keys":[
      {
         "kty":"RSA",
         "alg":"RS256",
         "use":"sig",
         "kid":"ca04df587b5a7cead80abee9ea8dcf7586a78e01",
         "n":"iXn-WmrwLLBa-QDiToBozpu4Y4ThKdwORWFXQa9I75pKOvPUjUjE2Bk05TUSt7-V7KDjCq0_Nkd-X9rMRV5LKgCa0_F8YgI30QS3bUm9orFryrdOc65PUIVFVxIwMZuGDY1hj6HEJVWIr0CZdcgNIll06BasclckkUK4O-Eh7MaQrqb646ghFlG3zlgk9b2duHbDOq3s39ICPinRQWC6NqTYfqg7E8GN_NLY9srUCc_MswuUfMJ2cKT6edrhLuIwIj_74YGkpOwilr2VswKsvJ7dcoiJxheKYvKDKtZFkbKrWETTJSGX2Xeh0DFB0lqbKLVvqkM2lFU2Qx1OgtTnrw",
         "e":"AQAB"
      },
      {
          "kty":"EC",
          "alg":"ES256",
          "use":"enc",
          "kid":"k05TUSt7-V7KDjCq0_N"
          "crv":"P-256",
          "x":"Xej56MungXuFZwmk_xccvsMpCtXmqhvEEMCmHyAmKF0",
          "y":"Bozpu4Y4ThKdwORWFXQa9I75pKOvPUjUjE2Bk05TUSt",
      }
   ]
}

Разработка прокси-сервера для использования JWKS

Когда JWS/JWT получают от эмитента, часто эмитент вставляет в заголовок JWS/JWT идентификатор ключа (или kid). Этот ключ сообщает получателю JWS/JWT, как найти открытый или секретный ключ, необходимый для проверки подписи подписанного JWS/JWT.

В качестве примера предположим, что эмитент подписывает JWT закрытым ключом. "Идентификатор ключа" определяет соответствующий открытый ключ, используемый для проверки JWT. Список открытых ключей обычно доступен по какой-либо известной конечной точке, например: https://www.googleapis.com/oauth2/v3/certs .

Это основная последовательность действий, которую Edge (или любая другая платформа, работающая с JWKS) должна выполнить для работы с JWS/JWT, содержащим JWKS-файл:

  1. Изучите заголовок JWS/JWT, чтобы найти идентификатор ключа (kid).
  2. Изучите заголовок JWS/JWT, чтобы найти алгоритм подписи (alg), например, RS256.
  3. Получите список ключей и идентификаторов из JWKS-файла известной конечной точки для заданного эмитента.
  4. Извлеките открытый ключ из списка ключей, используя идентификатор ключа, указанный в заголовке JWS/JWT, и соответствующий алгоритм, если алгоритм указан в ключе JWKS.
  5. Используйте этот открытый ключ для проверки подписи JWS/JWT.

Разработчику прокси-серверов Edge API необходимо выполнить следующие действия для проверки JWS/JWT:

  1. Получите список ключей и идентификаторов из общеизвестной конечной точки для заданного эмитента. Для этого шага можно использовать политику вызова сервиса.
  2. В политике проверки JWS/JWT укажите местоположение JWS/JWT в элементе <Source> , а полезную нагрузку JWKS — в элементе <PublicKey/JWKS> . Например, для политики проверки JWT: 
    <VerifyJWT name="JWT-Verify-RS256">
    <Algorithm>RS256</Algorithm>
    <Source>json.jwt</Source>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <PublicKey>
        <JWKS ref="public.jwks"/>
    </PublicKey>
    <Subject>apigee-seattle-hatrack-montage</Subject>
    <Issuer>urn://apigee-edge-JWT-policy-test</Issuer>
    <Audience>urn://c60511c0-12a2-473c-80fd-42528eb65a6a</Audience>
    <AdditionalClaims>
        <Claim name="show">And now for something completely different.</Claim>
    </AdditionalClaims>
</VerifyJWT>

Политика проверки JWT выполняет все остальные действия:

  • Если в JWKS не найден ключ с идентификатором, совпадающим с идентификатором ключа (kid), указанным в JWT, то политика проверки JWT выдает ошибку и не проверяет JWT.
  • Если входящий JWT не содержит идентификатор ключа (kid) в заголовке, то сопоставление keyid с verification-key невозможно.

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