Se usó la API de Cloud Translation para traducir esta página.

Descripción general de las políticas de JWS y JWT

Esta página se aplica a Apigee y Apigee Hybrid.

Consulta la documentación de Apigee Edge.

En este tema, se proporciona información general sobre JWT (token web JSON), JWS (firma web JSON) y las políticas de Apigee JWS/JWT que pueden ser de interés para los desarrolladores del proxy de Apigee.

Introducción

JWS y JWT se usan, por lo general, para compartir reclamaciones o confirmaciones entre aplicaciones conectadas. Las políticas de JWS y JWT permiten que los proxies de la API de Apigee hagan lo siguiente:

Genera un JWT firmado, un JWS o un JWT encriptado.
Verifica un JWT firmado, un JWS o un JWT encriptado, y verifica las reclamacións seleccionadas dentro del JWS o JWT.
Decodifica un JWT firmado o encriptado o un JWS sin validar la firma ni desencriptar el JWT o JWS encriptado. En el caso de un JWS, la política DecodeJWS solo puede decodificar las reclamaciones en el encabezado del JWS. En el caso de un JWT encriptado, la política de DecodeJWT solo puede decodificar el encabezado no encriptado.

En los dos últimos casos, la política también establece variables de flujo. Esto permite que las políticas posteriores del flujo de Apigee inspeccionen las reclamaciones en el JWT o JWS, tomen decisiones en función de esas reclamaciones o propaguen esa información a los servicios de backend.

Cuando usas las políticas VerifyJWS o VerifyJWT, se rechazará un JWS/JWT no válida y se generará una condición de error. De manera similar, cuando se usan las políticas DecodeJWS o DecodeJWT, un JWS/JWT con formato incorrecto tendrá una condición de error.

Videos

Mira un breve video para obtener una introducción rápida a JWT. Si bien este video es específico a fin de generar un JWT, muchos de los conceptos son los mismos para JWS.

Un video corto para obtener más información sobre la estructura JWT.

Casos de uso

Puedes usar las políticas de JWS/JWT para hacer lo siguiente:

Generar un nuevo JWS/JWT en los extremos del proxy de destino o del proxy de un proxy de Apigee. Por ejemplo, puedes crear un flujo de solicitud de proxy que genere un JWS/JWT y lo devuelva a un cliente. También puedes diseñar un proxy para que genere un JWS/JWT en el flujo de solicitud de destino y lo adjunte a la solicitud enviada al destino. Luego, el JWS/JWT y sus reclamaciones estarán disponibles para permitir que los servicios de backend apliquen más procesos de seguridad.
Verificar y extraer reclamaciones de un JWS/JWT que se obtiene de las solicitudes de cliente entrantes, de las respuestas del servicio de destino, de las respuestas de las políticas de texto destacado del servicio o de otras fuentes. Para un JWS/JWT firmado, Apigee usará uno de los algoritmos RSA, ECDSA o HMAC para verificar la firma, ya sea que Apigee o un tercero haya generado el JWS/JWT. En el caso de un JWT encriptado, Apigee desencriptará el JWT con uno de los algoritmos de encriptación de JWA admitidos (consulta IETF RFC 7518).
Decodificar un JWS/JWT. La decodificación es más útil cuando se usa junto con la política Verify JWS/JWT, en los casos en que se debe conocer el valor de una reclamación (JWT) o encabezado (JWS/JWT) dentro del JWS/JWT antes de verificar un JWS/JWT firmado o desencriptar un JWT encriptado.

Partes de un JWS/JWT

Un JWS/JWT firmado codifica la información en tres partes separadas por puntos:

Header.Payload.Signature

La política de generación de JWS/JWT crea las tres partes.
La política de verificación de JWS/JWT examina las tres partes.
La política DecodeJWS solo examina el encabezado. La política de DecodeJWT solo examina el encabezado y la carga útil.

Un JWS también admite un formato desconectado que omite la carga útil del JWS:

Header..Signature

Con un JWS desconectado, la carga útil se envía por separado del JWS. Usa el elemento <DetachedContent> de la política de verificación de JWS para especificar la carga útil de JWS sin codificar ni procesar. Luego, la política de verificación de JWS verifica el JWS con el encabezado y la firma en el JWS y la carga útil especificada por el elemento <DetachedContent>.

Un JWT encriptado codifica la información en cinco partes separadas por puntos:

Header.Key.InitializationVector.Payload.AuthenticationTag

Las políticas GenerateJWT y VerifyJWT crearán o examinarán todas esas partes. DecodeJWT solo puede examinar el encabezado no encriptado.

Para obtener más información sobre los tokens y la forma en que se codifican, firman o encriptan, consulta los documentos de estándares relevantes:

JWT: IETF RFC7519
JWS: IETF RFC7515

Diferencias entre JWS y JWT

Puedes usar un JWT o JWS para compartir reclamaciones o confirmaciones entre aplicaciones conectadas. La principal diferencia entre los dos es la representación de la carga útil:

JWT
- La carga útil siempre es un objeto JSON.
- La carga útil siempre se adjunta al JWT
- El encabezado typ del token siempre se configura como JWT
- La carga útil puede estar firmada o encriptada.
JWS
- La carga útil se puede representar mediante cualquier formato, como un objeto JSON, una transmisión de bytes, una transmisión de octeto y otros.
- No es necesario adjuntar la carga útil al JWS
- El encabezado y la carga útil siempre están firmados. JWS no admite la encriptación.

Debido a que el formato JWT siempre usa un objeto JSON a fin de representar la carga útil, las políticas GenerateJWT and VerifyJWT de Apigee que se crearon tienen compatibilidad para manejar nombres de reclamaciones registradas comunes, como aud, iss, sub y otros. Esto significa que puedes usar elementos de la política GenerateJWT para configurar estas reclamaciones en la carga útil y los elementos de la política VerifyJWT para verificar sus valores. Consulta la sección Nombres de reclamacións registrados de la especificación JWT para obtener más información.

Además de admitir ciertos nombres de reclamacións registrados, la política GenerateJWT admite directamente la adición de reclamacións con nombres arbitrarios a la carga útil o al encabezado de la JWT. Cada reclamación es un par nombre/valor simple, en el que el valor puede ser de tipo number, boolean, string, map o array.

Cuando usas GenerateJWS, proporcionas una variable de contexto que representa la carga útil. Debido a que un JWS puede usar cualquier representación de datos para la carga útil, no existe el concepto de "reclamación de carga útil" en un JWS, y la política GenerateJWS no admite la adición de reclamaciones con nombres arbitrarios a la carga útil. Es posible usar la política GenerateJWS para agregar reclamacións con nombres arbitrarios al encabezado de la JWS. Además, las políticas JWS admiten una carga útil desconectada, en la que JWS omite la carga útil. Una carga útil desconectada te permite enviar el JWS y la carga útil por separado. El uso de una carga útil desconectada puede ser más eficiente en el espacio, especialmente para cargas útiles grandes, y es obligatorio para varios estándares de seguridad.

Firma en comparación con la encriptación

Apigee puede generar JWT firmados o encriptados. Elige un JWT firmado cuando la carga útil no tenga que ser secreta, pero es importante proporcionar garantías de integridad y no rechazo a los lectores. Un JWT firmado les garantiza a los lectores que la carga útil no cambió desde que se firmó el JWT y que el titular de la clave privada lo firmó. Elige JWT encriptado cuando la carga útil deba ser secreta. Un JWT encriptado proporciona confidencialidad para la carga útil, ya que solo el titular de la clave adecuada puede desencriptarla.

Es posible usar JWT encriptados y firmados juntos, en especial cuando el JWT encriptado usa un algoritmo de criptografía asimétrica (RSA, ECDSA). En ese caso, no se puede determinar la identidad del productor de ese JWT, ya que la clave de encriptación es pública. Para abordar ese problema, combina la firma con la encriptación. Un patrón típico es el siguiente:

Firma una carga útil para producir un JWS o un JWT firmado.
Encripta el resultado firmado para producir un JWT encriptado.

Incorporar una carga útil firmada en un JWT encriptado con este enfoque proporciona garantías de no rechazo y confidencialidad. Las políticas de Apigee pueden producir, decodificar y verificar esas combinaciones.

Algoritmos de firma

Para las políticas JWS/JWT y de verificación de JWS/JWT, se admiten algoritmos RSA, RSASSA-PSS, ECDSA y HMAC, mediante sumas de comprobación SHA2 de intensidad de bit de 256, 384 o 512. Las políticas DecodeJWS y DecodeJWT funcionan independientemente del algoritmo que se usó para firmar el JWS/JWT.

Algoritmos HMAC

El algoritmo HMAC depende de un secreto compartido, conocido como la clave secreta, para crear la firma (también conocida como la firma de JWS/JWT) y verificarla.

La longitud mínima de la clave secreta depende de la intensidad de bits del algoritmo:

HS256: Longitud mínima de clave de 32 bytes
HS384: Longitud mínima de la clave de 48 bytes
HS512: Longitud mínima de clave de 64 bytes

Algoritmos RSA

Los algoritmos de RSA usan un par de clave pública/privada para la firma criptográfica. La especificación de JWA usa los sobrenombres RS256, RS384 y RS512 para representar estas opciones. Con las firmas de RSA, la parte de firma usa una clave privada RSA para firmar el JWS/JWT y la parte verificada usa la clave pública RSA correspondiente a fin de verificar la firma en el JWS/JWT. No hay requisitos de tamaño para las claves.

Algoritmos RSASSA-PSS

Los algoritmos RSASSA-PSS son una actualización de los algoritmos RSA y usan los sobrenombres PS256, PS384 y PS512. Al igual que las variantes de RS*, RSASSA-PSS usa un par de clave pública/privada RSA para la firma criptográfica. El formato, el mecanismo y los límites de tamaño de la clave son los mismos que para los algoritmos RS*.

Algoritmos ECDSA

El conjunto de algoritmos de firma digital de curva elíptica (ECDSA) son algoritmos de criptografía de curva elíptica con una curva P-256, P-384 o P-521. Cuando usas algoritmos de ECDSA, el algoritmo determina el tipo de clave pública y privada, debes especificar lo siguiente:

Algoritmo	Curva	Requisito de la clave
ES256	P-256	Una clave generada a partir de la curva P-256 (también conocida como secp256r1 o prime256v1)
ES384	P-384	Una clave generada a partir de la curva P-384 (también conocida como secp384r1)
ES512	P-521	Una clave generada a partir de la curva P-521 (también conocida como secp521r1)

Algoritmos de encriptación

Cuando se usan GenerateJWT y VerifyJWT para controlar JWT encriptados, las políticas admiten estos algoritmos:

dir
RSA-OAEP-256
A128KW, A192KW, A256KW
A128GCMKW, A192GCMKW, A256GCMKW
PBES2-HS256+A128KW, PBES2-HS384+A192KW, PBES2-HS512+A256KW
ECDH-ES, ECDH-ES+A128KW, ECDH-ES+A192KW, ECDH-ES+A256KW

Claves y representaciones de claves

Los estándares JOSE, que abarcan JWS, JWT firmados y encriptados, y mucho más, describen cómo usar las claves criptográficas para firmar o encriptar información. Los elementos fundamentales de cualquier operación criptográfica incluyen el algoritmo y la clave. Los diferentes algoritmos requieren diferentes tipos de claves y, en algunos casos, diferentes tamaños de claves.

Los algoritmos simétricos, como la familia HS* para la firma o el algoritmo A128KW para la encriptación, requieren claves simétricas o compartidas: se usa la misma clave para firmar y verificar, o la misma clave para encriptar y desencriptar. Los algoritmos asimétricos, como los algoritmos RS*, PS* y ES* para la firma, o los algoritmos ECDH* para la encriptación, usan pares de claves: hay una clave pública y una privada, y ambas coinciden. En la firma, el firmante usa la clave privada para firmar, y cualquier parte puede usar la clave pública para verificar la firma. En la encriptación, el algoritmo de encriptación usa la clave pública para encriptar, y el algoritmo de desencriptación usa la clave privada para desencriptar. Las claves públicas, como su nombre indica, se pueden compartir públicamente y no es necesario mantenerlas en secreto.

Existen diferentes formas de serializar claves criptográficas en formato de texto. Las políticas de Apigee aceptan claves serializadas en varios formatos: formato PEM codificado, formato JWKS o, para claves compartidas, formato UTF-8 o base64 codificado.

Formato PEM

Para las claves públicas o privadas, es común usar la codificación PEM, que se define en la RFC 7468 de IETF. Este es un ejemplo de una clave privada representada en formato PEM:

Existen formatos PEM similares para claves públicas o claves privadas encriptadas.

Formato JWKS

Una clave web JSON (JWK) es una estructura de datos JSON que representa una sola clave criptográfica. Un conjunto de claves web JSON (JWKS) es una estructura JSON que representa un conjunto de JWK. JWK y JWKS se describen en RFC7517. Consulta ejemplos de JWKS en el Apéndice A. Ejemplo de conjuntos de claves web JSON

El objetivo de JWKS es permitir que cualquier parte represente un conjunto de claves en un formato estándar. Un caso de uso clave es compartir claves públicas de forma estándar, a través de un extremo HTTP que entrega datos en formato JWKS. Cuando una empresa o un sistema que genera JWS o JWT firmados, como un proveedor de identidad, publica sus claves públicas, cualquier sistema o aplicación que pueda leer las claves públicas puede verificar las firmas generadas por la parte que firma. Por el contrario, cualquier sistema o aplicación que desee encriptar datos que solo debe leer una parte o empresa en particular puede recuperar las claves públicas que pertenecen a esa parte o empresa y generar un JWT encriptado para ese fin.

RFC7517 describe los elementos clave de JWKS para cada tipo de clave, como RSA o EC. Estos elementos siempre deben estar presentes:

kty: Es el tipo de clave, como RSA o EC.
kid: Es el ID de clave. Puede ser cualquier valor de cadena única arbitraria. No debe haber duplicados dentro de un solo conjunto de claves. Si el JWT entrante ingresa un ID de clave presente en el conjunto de JWKS, las políticas VerifyJWS o VerifyJWT usarán la clave pública correcta para verificar la firma de JWS/JWT.

A continuación, se presentan ejemplos de elementos opcionales y sus valores:

alg: Es el algoritmo clave. Debe coincidir con el algoritmo de firma del JWS/JWT.
uso: el uso previsto de la clave. Los valores típicos son “sig” para la firma y verificación, o “enc” para la encriptación y desencriptación.

El siguiente JWKS (recuperado originalmente de https://www.googleapis.com/oauth2/v3/certs, pero desactualizado) incluye los elementos y valores necesarios, y Apigee podría usarlo:

{
     "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",
        }
     ]
  }

Especifica claves para las políticas de JWS y JWT

Ya sea que generes o verifiques JWS o JWT, debes proporcionar una clave para usar en las operaciones criptográficas.

Cuando generas un JWT firmado, debes proporcionar una clave que pueda producir la firma.

En el caso de un algoritmo de firma RS*, PS* o ES*, que usan claves asimétricas, debes proporcionar la clave privada para generar la firma.
En el caso de un algoritmo HS*, debes proporcionar la clave simétrica que se usará cuando se genere la firma.

Cuando verificas un JWS/JWT firmado, debes proporcionar una clave que pueda verificar la firma.

En el caso de un algoritmo de firma RS*, PS* o ES*, debes proporcionar la clave pública asociada con la clave privada que se usó originalmente para firmar el token.
En el caso de un algoritmo HS*, debes proporcionar la misma clave simétrica que se usó para firmar el JWS o el JWT.

Tienes dos opciones para proporcionar las claves a las políticas de JWS y JWT:

Proporciona el valor de la clave directamente (por lo general, a través de una variable de contexto), o
Proporciona la clave de forma indirecta a través de un kid y un JWKS. Puedes especificar el JWKS directamente o indirectamente a través de una URL HTTP en la que Apigee pueda recuperar el JWKS.

Por lo general, la opción de URL de JWKS solo se usa como fuente de claves públicas que se pueden usar con algoritmos asimétricos, ya que las URLs de JWKS suelen ser públicas.

En los siguientes ejemplos, se ilustran las formas en que puedes proporcionar claves directamente en varias situaciones.

Genera un JWT firmado con el algoritmo HSD256. La clave requerida en este caso es una clave simétrica. Esta política proporciona una variable de contexto que contiene la clave secreta codificada en base64url.

<GenerateJWT name='gen-138'>
  <Algorithm>HS256</Algorithm>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <SecretKey encoding='base64url'>
    <Value ref='private.secretkey'/>
    <Id ref='variable-containing-desired-keyid'/>
  </SecretKey>
  . . .
  <OutputVariable>output_variable_name</OutputVariable>
</GenerateJWT>

Verifica un JWT firmado con el algoritmo HS256. La clave requerida en este caso es una clave simétrica. Al igual que en el ejemplo anterior, esta política proporciona una variable de contexto que contiene la clave secreta codificada en base64url.

<VerifyJWT name='verify-138'>
  <Algorithm>HS256</Algorithm>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <SecretKey encoding='base64url'>
    <Value ref='private.secretkey'/>
  </SecretKey>
  . . .
  <OutputVariable>output_variable_name</OutputVariable>
</VerifyJWT>

Verifica un JWT firmado con el algoritmo PS256. La clave requerida en este caso es una clave pública RSA. Esta política proporciona una variable de contexto que contiene la clave pública con codificación PEM.

<VerifyJWT name='JWT-001'>
  <Algorithm>PS256</Algorithm>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <PublicKey>
    <Value ref='variable-containing-pem-encoded-public-key'/>
  </PublicKey>
  . . .
</VerifyJWT>

Genera un JWT firmado con el algoritmo PS256. La clave requerida en este caso es una clave privada de RSA. Esta política proporciona una variable de contexto que contiene la clave privada con codificación PEM.

<GenerateJWT name='JWT-002'>
  <Algorithm>PS256</Algorithm>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <PrivateKey>
    <Value ref='private.variable-containing-pem-encoded-private-key'/>
  </PrivateKey>
   . . .
</GenerateJWT>

JWKS como fuente de claves cuando se verifica un JWS o un JWT firmado

Cuando un sistema o una app generan un JWS/JWT, por lo general, insertan un identificador de clave (el reclamo kid) en el encabezado JWS/JWT. La clave le indica a cualquier lector del JWS/JWT qué clave se requiere para verificar la firma en el JWS/JWT firmado o desencriptar el JWT encriptado.

A modo de ejemplo, supongamos que una entidad emisora firma un JWT con una clave privada. El “ID de clave” identifica la clave pública coincidente que se debe usar para verificar el JWT. Por lo general, la lista de claves públicas está disponible en algún extremo conocido, como el extremo de identidad de Google o el extremo de Firebase Authentication. Otros proveedores tendrán sus propios extremos públicos que publican claves en formato JWKS.

Cuando usas Apigee para verificar un JWS o un JWT firmado con claves públicas que se comparten a través de un extremo de JWKS, tienes algunas opciones:

Opción 1: En la configuración de la política, especifica el URI del extremo de JWKS en el elemento <PublicKey/JWKS>. Por ejemplo, para la política VerifyJWT:
```
<VerifyJWT name="JWT-Verify-RS256">
  <Algorithm>RS256</Algorithm>
  <Source>json.jwt</Source>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <PublicKey>
      <JWKS uri="https://www.googleapis.com/oauth2/v3/certs"/>
  </PublicKey>
  . . .
</VerifyJWT>
```
En este caso, Apigee hará lo siguiente:
1. Examina el encabezado JWS/JWT para encontrar el algoritmo de firma (alg), como RS256, y rechaza el JWT entrante si ese algoritmo no coincide con el algoritmo configurado en la política.
2. Recupera la lista de claves con sus IDs del extremo de JWKS especificado o de una caché interna si ya se usó este extremo de JWKS.
3. Examine el encabezado JWS/JWT para encontrar el ID de clave (kid). Si el JWT entrante no incluye un ID de clave (kid) en el encabezado, no es posible asignar kid a verification-key, y Apigee arrojará una falla.
4. Extrae del JWKS el JWK con el ID de clave que se indica en el encabezado JWS/JWT. Genera una falla si no hay una clave con ese ID de clave.
5. Verifica que el algoritmo del JWK coincida con el algoritmo especificado en la configuración de la política. Rechaza la verificación y muestra un error si los algoritmos no coinciden.
6. Usa esa clave pública para verificar la firma en el JWS/JWT. Rechaza la verificación y muestra un error si la firma no se verifica.
Opción 2: En la configuración de la política, especifica una variable que contenga el URI del extremo de JWKS en el elemento <PublicKey/JWKS>.

Por ejemplo, para la política VerifyJWT:
```
<VerifyJWT name="JWT-Verify-RS256">
  <Algorithm>RS256</Algorithm>
  <Source>json.jwt</Source>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <PublicKey>
    <JWKS uriRef="variable-containing-a-uri"/>
  </PublicKey>
  . . .
</VerifyJWT>
```
En este caso, Apigee realizará los mismos pasos que antes, excepto que recuperará el JWKS no de un URI hard-coded, sino del URI especificado en la variable a la que hace referencia el atributo uriRef. Se seguirá aplicando el almacenamiento en caché.

Nota: Ten cuidado cuando uses el atributo uriRef. Como diseñador de proxy, eres responsable de asegurarte de no configurar tus políticas de verificación para que confíen en URIs no verificados. Por ejemplo, sería una práctica no segura si decodificaras el JWS o JWT entrante, recuperaras un URI de JWKS del encabezado y, luego, verificaras el JWS o JWT desde ese URI, sin verificar primero que el URI esté en una lista de confianza.
Opción 3: En la configuración de la política, especifica una variable que contenga los datos de JWKS hard-coded en el elemento <PublicKey/JWKS>.

Por ejemplo, para la política VerifyJWT:
```
<VerifyJWT name="JWT-Verify-RS256">
  <Algorithm>RS256</Algorithm>
  <Source>json.jwt</Source>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <PublicKey>
    <JWKS ref="variable-that-holds-a-jwks"/>
  </PublicKey>
  . . .
</VerifyJWT>
```
En este caso, Apigee realizará los mismos pasos que antes, excepto que recuperará el JWKS no de un URI, sino de la variable de contexto que especifiques en el atributo ref. Por lo general, habrías cargado esta variable de contexto desde un ServiceCallout, un KVM o un archivo de propiedades asociado al proxy.

Nota: Si usas un ServiceCallout para recuperar los JWKS, se recomienda almacenar en caché los JWKS para evitar ejecutar el ServiceCallout en cada solicitud.

JWKS como fuente de claves cuando se genera un JWT encriptado

Cuando generas un JWT encriptado a través de un algoritmo asimétrico (RSA-OAEP-256 o cualquiera de las variantes de ECDH-*), usas la clave pública para encriptar. Tienes opciones para proporcionar la clave a la política de GenerateJWT.

Un enfoque típico es especificar en la configuración de la política el URI del extremo JWKS en el elemento <PublicKey/JWKS>. Por ejemplo:

<GenerateJWT name="GJWT-1">
  <Algorithms>
    <Key>RSA-OAEP-256</Key>
    <Content>A128GCM</Content>
  </Algorithms>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <PublicKey>
    <JWKS uri='https://www.example.com/.well-known/jwks.json'/>
    <Id ref='variable-containing-desired-keyid'/>
  </PublicKey>
    . . .
</GenerateJWT>

En este caso, Apigee hará lo siguiente:

Ensambla la carga útil y el encabezado sin codificar del JWT según la configuración de la política.
Recupera la lista de claves con sus IDs del extremo de JWKS especificado o de una caché interna si ya se usó este extremo de JWKS. Actualmente, el TTL de la caché es de 5 minutos.
Extrae el JWK con el ID de clave indicado en el elemento PublicKey/Id del JWKS. Genera una falla si no hay una clave con ese ID de clave.
Comprueba que el algoritmo del JWK coincida con el algoritmo especificado en la configuración de la política. Genera una falla si los algoritmos no coinciden.
Genera una secuencia aleatoria que se usará como clave de encriptación de contenido.
Usa la clave pública seleccionada para encriptar la clave de encriptación de contenido.
Usa la clave de encriptación de contenido para encriptar la carga útil.
Por último, ensambla todas las partes en un JWT encriptado y serializado.

Una alternativa es usar el atributo uriRef para especificar una variable que contenga el URI de un extremo de JWKS. Por ejemplo:

<GenerateJWT name="GJWT-1">
  <Algorithms>
    <Key>RSA-OAEP-256</Key>
    <Content>A128GCM</Content>
  </Algorithms>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <PublicKey>
    <JWKS uriRef='variable-containing-jwks-uri'/>
    <Id ref='variable-containing-desired-keyid'/>
  </PublicKey>
  . . .
</GenerateJWT>

En este caso, Apigee realizará los mismos pasos que antes, excepto que recuperará el JWKS del URI especificado en la variable a la que hace referencia el atributo uriRef, en lugar de un URI hard-coded. Apigee leerá el JWKS desde una caché interna si este extremo de JWKS se usó antes.