Esta página se ha traducido con Cloud Translation API.

Información general sobre 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 (JSON Web Token) y JWS (JSON Web Signature), así como sobre las políticas de JWS y JWT de Apigee que pueden ser de interés para los desarrolladores de proxies de Apigee.

Introducción

Tanto JWS como JWT se suelen usar para compartir reclamaciones o aserciones entre aplicaciones conectadas. Las políticas de JWS y JWT permiten que los proxies de API de Apigee hagan lo siguiente:

Generar un JWT firmado o un JWS o un JWT cifrado.
Verifica un JWT firmado o un JWS, o un JWT cifrado y verifica las reclamaciones seleccionadas en el JWS o JWT.
Decodifica un JWT firmado o cifrado o un JWS sin validar la firma ni descifrar el JWT o el JWS cifrado. En el caso de un JWS, la política DecodeJWS solo puede decodificar las reclamaciones del encabezado del JWS. En el caso de un JWT cifrado, la política DecodeJWT solo puede decodificar el encabezado sin cifrar.

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

Cuando se usan las políticas VerifyJWS o VerifyJWT, se rechaza un JWS o JWT no válido y se produce un error. Del mismo modo, al usar las políticas DecodeJWS o DecodeJWT, si un JWS o JWT tiene un formato incorrecto, se producirá un error.

Vídeos

Echa un vistazo a este breve vídeo para conocer los aspectos básicos de los JWTs. Aunque este vídeo se centra en la generación de un JWT, muchos de los conceptos son los mismos para JWS.

Echa un vistazo a este breve vídeo para obtener más información sobre la estructura de los JWTs.

Casos prácticos

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

Genera un nuevo JWS o JWT en el proxy de Apigee o en el endpoint de destino. Por ejemplo, puedes crear un flujo de solicitudes de proxy que genere un JWS o JWT y lo devuelva a un cliente. También puedes diseñar un proxy para que genere un JWS o JWT en el flujo de solicitudes de destino y lo adjunte a la solicitud enviada al destino. El JWS o JWT y sus reclamaciones estarían disponibles para que los servicios de backend apliquen un procesamiento de seguridad adicional.
Verifica y extrae las reclamaciones de un JWS o JWT obtenido de solicitudes de clientes entrantes, de respuestas de servicios de destino, de respuestas de políticas de Service Callout o de otras fuentes. En el caso de un JWS o JWT firmado, Apigee usará uno de los algoritmos RSA, ECDSA o HMAC para verificar la firma, independientemente de si el JWS o JWT lo ha generado Apigee o un tercero. En el caso de un JWT cifrado, Apigee descifrará el JWT mediante uno de los algoritmos de cifrado de JWA admitidos (consulta el RFC 7518 de IETF).
Decodifica un JWS o un JWT. La decodificación es más útil cuando se usa junto con la política Verificar JWS/JWT, en los casos en los que se debe conocer el valor de una reclamación (JWT) o un encabezado (JWS/JWT) dentro del JWS/JWT antes de verificar un JWS/JWT firmado o descifrar un JWT cifrado.

Partes de un JWS o JWT

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

Header.Payload.Signature

La política Generar JWS/JWT crea las tres partes.
La política Verificar JWS/JWT examina las tres partes.
La política DecodeJWS solo examina el encabezado. La política DecodeJWT solo examina el encabezado y la carga útil.

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

Header..Signature

Con un JWS independiente, la carga útil se envía por separado del JWS. Utiliza el elemento <DetachedContent> de la política Verify JWS para especificar la carga útil de JWS sin codificar. La política Verify JWS verifica el JWS mediante el encabezado y la firma del JWS, así como la carga útil especificada por el elemento <DetachedContent>.

Un JWT cifrado 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 sin cifrar.

Para obtener más información sobre los tokens y cómo se codifican, firman o cifran, consulta los documentos de estándares correspondientes:

JWT IETF RFC7519
JWS IETF RFC7515

Diferencias entre JWS y JWT

Puedes usar un JWT o un JWS para compartir reclamaciones o aserciones entre aplicaciones conectadas. La principal diferencia entre ambos 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 define como JWT.
- La carga útil puede estar firmada o cifrada.
JWS
- La carga útil se puede representar en cualquier formato, como un objeto JSON, un flujo de bytes, un flujo de octetos, etc.
- No es necesario adjuntar la carga útil al JWS.
- El encabezado y la carga útil siempre están firmados. JWS no admite el cifrado.

Como el formato JWT siempre usa un objeto JSON para representar la carga útil, las políticas GenerateJWT y VerifyJWT de Apigee tienen asistencia integrada para gestionar nombres de reclamaciones registrados comunes, como aud, iss, sub y otros. Esto significa que puede usar elementos de la política GenerateJWT para definir estas reclamaciones en la carga útil y elementos de la política VerifyJWT para verificar sus valores. Para obtener más información, consulta la sección Registered Claim Names (Nombres de reclamaciones registradas) de la especificación JWT.

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

Cuando se usa GenerateJWS, se proporciona una variable de contexto que representa la carga útil. Como 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 añadir reclamaciones con nombres arbitrarios al encabezado del JWS. Además, las políticas de JWS admiten una carga útil independiente, en la que JWS omite la carga útil. Una carga útil independiente te permite enviar el JWS y la carga útil por separado. Usar una carga útil independiente puede ser más eficiente en cuanto al espacio, sobre todo en el caso de cargas útiles grandes, y es obligatorio en varias normas de seguridad.

Firma frente a cifrado

Apigee puede generar JWTs firmados o cifrados. Elige JWT firmado cuando la carga útil no tenga que ser secreta, pero sea importante ofrecer garantías de integridad y no repudio a los lectores. Un JWT firmado asegura a los lectores que la carga útil no ha cambiado desde que se firmó el JWT y que el JWT lo firmó el propietario de la clave privada. Elige JWT cifrado cuando la carga útil deba ser secreta. Un JWT cifrado proporciona confidencialidad a la carga útil, ya que solo el propietario de la clave adecuada puede descifrarla.

Es posible usar JWTs cifrados y firmados al mismo tiempo, sobre todo cuando el JWT cifrado usa un algoritmo de cifrado asimétrico (RSA, ECDSA). En ese caso, no se puede determinar la identidad del productor de ese JWT, ya que la clave de cifrado es pública. Para solucionar este problema, combina la firma con el cifrado. Un patrón habitual es el siguiente:

Firma una carga útil para generar un JWS o un JWT firmado.
Cifra el resultado firmado para generar un JWT cifrado.

Si insertas una carga útil firmada en un JWT cifrado con este método, se garantiza tanto la confidencialidad como la no repudiación. Las políticas de Apigee pueden generar y decodificar y verificar estas combinaciones.

Algoritmos de firma

En el caso de los JWT firmados, las políticas de verificación y generación de JWS/JWT admiten los algoritmos RSA, RSASSA-PSS, ECDSA y HMAC, que usan sumas de comprobación SHA2 con una longitud de bits de 256, 384 o 512. Las políticas DecodeJWS y DecodeJWT funcionan independientemente del algoritmo que se haya usado para firmar el JWS o el JWT.

Algoritmos HMAC

Los algoritmos HMAC se basan en un secreto compartido, conocido como clave secreta, para crear la firma (también conocida como firma de JWS o JWT) y para verificarla.

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

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

Algoritmos RSA

Los algoritmos RSA usan un par de claves pública/privada para la firma criptográfica. La especificación JWA usa los nombres RS256, RS384 y RS512 para representar estas opciones. Con las firmas RSA, la parte que firma usa una clave privada RSA para firmar el JWS o JWT, y la parte que verifica usa la clave pública RSA correspondiente para verificar la firma del JWS o 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 monikers PS256, PS384 y PS512. Al igual que las variantes RS*, RSASSA-PSS usa un par de claves pública y 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 ECDSA, el algoritmo determina el tipo de clave pública y privada que debes especificar:

Algoritmo	Curve	Requisito fundamental
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	Clave generada a partir de la curva P-521 (también conocida como secp521r1)

Algoritmos de cifrado

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

dir
RSA-OAEP-256
A128KW, A192KW y A256KW
A128GCMKW, A192GCMKW y 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 de JOSE, que abarcan JWS, JWT firmados y cifrados, y más, describen cómo usar claves criptográficas para firmar o cifrar información. Los elementos fundamentales de cualquier operación criptográfica son el algoritmo y la clave. Los distintos algoritmos requieren diferentes tipos de claves y, en algunos casos, diferentes tamaños de clave.

Los algoritmos simétricos, como la familia HS* para la firma o el algoritmo A128KW para el cifrado, requieren claves simétricas o compartidas: se usa la misma clave para firmar y verificar, o para cifrar y descifrar. Los algoritmos asimétricos, como los algoritmos RS*, PS* y ES* para firmar, o los algoritmos ECDH* para cifrar, usan pares de claves. Hay una clave pública y una clave privada, y están emparejadas. 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 el cifrado, el cifrador usa la clave pública para cifrar, y el descifrador usa la clave privada para descifrar. Las claves públicas, como su nombre indica, se pueden compartir públicamente y no es necesario mantenerlas en secreto.

Hay varias formas de serializar claves criptográficas en formato de texto. Las políticas de Apigee aceptan claves serializadas de varias formas: en formato codificado PEM, en formato JWKS o, en el caso de las claves compartidas, en formato codificado en UTF-8 o en base64.

Formato PEM

En el caso de las claves públicas o privadas, es habitual usar la codificación PEM, que se define en IETF RFC 7468. A continuación, se muestra un ejemplo de una clave privada representada en formato PEM:

Hay formatos PEM similares para claves públicas o claves privadas cifradas.

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 de JSON (JWKS) es una estructura JSON que representa un conjunto de JWKs. JWK y JWKS se describen en RFC7517. Consulta los ejemplos de JWKS en el apéndice A. Ejemplo de conjunto de claves web JSON Sets.

JWKS se ha diseñado para permitir que cualquier parte represente un conjunto de claves en un formato estándar. Un caso práctico clave es compartir claves públicas de forma estándar a través de un endpoint HTTP que proporcione datos en formato JWKS. Cuando una empresa o un sistema que genera JWS o JWT firmados, como un proveedor de identidades, 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 firmante. Por el contrario, cualquier sistema o aplicación que quiera cifrar datos que solo deba leer una parte o una empresa concretas puede recuperar las claves públicas que le pertenezcan y generar un JWT cifrado para ese fin.

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

kty: el tipo de clave, como RSA o EC.
kid: el ID de la clave. Puede ser cualquier valor de cadena único arbitrario. No debe haber duplicados en un mismo conjunto de claves. Si el JWT entrante tiene un ID de clave que está presente en el conjunto de JWKS, la política VerifyJWS o VerifyJWT usará la clave pública correcta para verificar la firma JWS o JWT.

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

alg: el algoritmo de la clave. Debe coincidir con el algoritmo de firma del JWS o JWT.
use: el uso previsto de la clave. Los valores habituales son "sig" para la firma y la verificación, o "enc" para el cifrado y el descifrado.

El siguiente JWKS (obtenido originalmente de https://www.googleapis.com/oauth2/v3/certs, pero ahora está obsoleto) 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",
        }
     ]
  }

Especificar claves en las políticas de JWS y JWT

Tanto si generas como si verificas JWS o JWT, debes proporcionar una clave para usarla en las operaciones criptográficas.

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

En el caso de los algoritmos 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*, debe proporcionar la clave simétrica que se usará al generar la firma.

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

En el caso de los algoritmos de firma RS*, PS* o ES*, debes proporcionar la clave pública asociada a 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 haya usado para firmar el JWS o el JWT.

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

Proporcionar el valor de la clave directamente (normalmente, a través de una variable de contexto)
Proporcionar la clave de forma indirecta, mediante un kid y un JWKS. Puede especificar el JWKS directamente o indirectamente a través de una URL HTTP en la que Apigee pueda recuperar el JWKS.

La opción de URL de JWKS se suele usar solo 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 formas de proporcionar claves directamente en diferentes situaciones.

Genera un JWT firmado con el algoritmo HS256. La clave obligatoria 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. En este caso, la clave obligatoria 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 que se haya firmado con el algoritmo PS256. En este caso, la clave necesaria es una clave RSA pública. Esta política proporciona una variable de contexto que contiene la clave pública codificada en 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. En este caso, la clave necesaria es una clave RSA privada. Esta política proporciona una variable de contexto que contiene la clave privada codificada con 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 al verificar un JWS o un JWT firmado

Cuando un sistema o una aplicación genera un JWS o un JWT, normalmente inserta un identificador de clave (la reclamación kid) en el encabezado del JWS o del JWT. La clave indica a cualquier lector del JWS o JWT qué clave se necesita para verificar la firma del JWS o JWT firmado, o para descifrar el JWT cifrado.

Por ejemplo, supongamos que una entidad emisora firma un JWT con una clave privada. El "ID de clave" identifica la clave pública correspondiente que se debe usar para verificar el JWT. La lista de claves públicas suele estar disponible en un endpoint conocido, como el endpoint de identidad de Google o el endpoint de autenticación de Firebase. Otros proveedores tendrán sus propios endpoints 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 endpoint JWKS, tienes varias opciones:

Opción 1: En la configuración de la política, especifica el URI del endpoint JWKS en el elemento <PublicKey/JWKS>. Por ejemplo, en 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 o 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 endpoint JWKS especificado o de una caché interna si este endpoint JWKS se ha usado antes.
3. Examina 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 se podrá asignar el kid a la clave de verificación y Apigee generará un error.
4. Extrae del JWKS el JWK con el ID de clave indicado en la cabecera JWS o JWT. Genera un error si no hay ninguna clave con ese ID.
5. Comprueba que el algoritmo de la JWK coincida con el algoritmo especificado en la configuración de la política. Rechaza la verificación y genera un error si los algoritmos no coinciden.
6. Usa esa clave pública para verificar la firma del JWS o JWT. Rechaza la verificación y genera un error si no se verifica la firma.
Opción 2: En la configuración de la política, especifica una variable que contenga el URI del endpoint JWKS en el elemento <PublicKey/JWKS>.

Por ejemplo, en 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 se han descrito anteriormente, con la diferencia de que Apigee recuperará el JWKS no de un URI codificado, sino del URI especificado en la variable a la que hace referencia el atributo uriRef. El almacenamiento en caché sigue aplicándose.

Nota: Tenga cuidado al usar el atributo uriRef. Como diseñador del proxy, es tu responsabilidad asegurarte de que no configuras tus políticas de verificación para que confíen en URIs no verificadas. Por ejemplo, sería una práctica poco segura si descodificaras el JWS o el JWT entrante, obtuvieras un URI de JWKS del encabezado y, a continuación, verificaras el JWS o el 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 codificados en el elemento <PublicKey/JWKS>.

Por ejemplo, en 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 se han descrito anteriormente, excepto que Apigee obtendrá el JWKS no de un URI, sino de la variable de contexto que especifiques en el atributo ref. Normalmente, esta variable de contexto se carga desde un elemento ServiceCallout, un elemento KVM o un archivo de propiedades asociado al proxy.

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

JWKS como fuente de claves al generar un JWT cifrado

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

Una práctica habitual es especificar en la configuración de la política el URI del endpoint 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:

Monta la carga útil y el encabezado sin codificar del JWT en función de la configuración de la política.
Recupera la lista de claves con sus IDs del endpoint JWKS especificado o de una caché interna si se ha usado este endpoint JWKS anteriormente. 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 un error si no hay ninguna clave con ese ID.
Comprueba que el algoritmo de la JWK coincida con el algoritmo especificado en la configuración de la política. Genera un error si los algoritmos no coinciden.
Genera una secuencia aleatoria que se usará como clave de cifrado de contenido.
Usa la clave pública seleccionada para cifrar la clave de cifrado de contenido.
Usa la clave de cifrado de contenido para cifrar la carga útil.
Por último, ensambla todas las partes en un JWT cifrado serializado.

Otra opción es usar el atributo uriRef para especificar una variable que contenga el URI de un endpoint 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 se han descrito anteriormente, con la diferencia de que Apigee obtendrá el JWKS del URI especificado en la variable a la que hace referencia el atributo uriRef, en lugar de un URI codificado. Apigee leerá el JWKS de una caché interna si se ha usado este endpoint de JWKS anteriormente.