Présentation des règles JWS et JWT

Cette page s'applique à Apigee et à Apigee hybrid.

Consultez la documentation d' Apigee Edge.

Cet article fournit des informations générales sur les jetons JWT (jeton Web JSON) et JWS (JSON Web Signature), ainsi que sur les règles Apigee JWS/JWT susceptibles d'intéresser les développeurs de proxy Apigee.

Introduction

Les jetons JWS et JWT sont couramment utilisés pour partager des revendications ou des assertions entre des applications connectées. Les règles JWS/JWT permettent aux proxys d'API Apigee d'effectuer les opérations suivantes :

Générer un JWT signé ou un JWS, ou un JWT chiffré.
Valider un jeton JWT signé ouun jeton JWS ou un jeton JWT chiffré et valider les revendications sélectionnées dans le JWS/JWT.
Décoder un jeton JWT signé ou chiffré ou un JWS sans valider la signature ni déchiffrer le jeton JWT ou JWS chiffré. Dans le cas d'un JWS, la règle DecodeJWS ne peut décoder que les revendications de l'en-tête du JWS. Dans le cas d'un jeton JWT chiffré, la règle DecodeJWT ne peut décoder que l'en-tête non chiffré.

Dans ces deux cas, la règle définit également des variables de flux. Cela permet aux règles ultérieures du flux Apigee d'inspecter les revendications du jeton JWT ou JWS et de prendre des décisions basées sur ces revendications, ou de propager ces informations aux services de backend.

Lorsque vous utilisez les règles VerifyJWS ou VerifyJWT, un jeton JWS/JWT non valide est rejeté et génère une condition d'erreur. De même, lorsque vous utilisez les règles DecodeJWS ou DecodeJWT, un jeton JWS/JWT mal mis en forme entraîne une condition d'erreur.

Vidéos

Regardez une courte vidéo pour découvrir rapidement le jeton JWT. Bien que cette vidéo soit spécifique à la génération d'un jeton JWT, de nombreux concepts sont les mêmes pour JWS.

Regardez une courte vidéo pour en savoir plus sur la structure JWT.

Cas d'utilisation

Vous pouvez utiliser les règles JWS/JWT pour :

Générer un nouveau jeton JWS/JWT au niveau du proxy ou du point de terminaison cible d'un proxy Apigee. Par exemple, vous pouvez créer un flux de requêtes proxy qui génère un JWS/JWT et le renvoie à un client. Vous pouvez également concevoir un proxy pour qu'il génère un jeton JWS/JWT sur le flux de requêtes cible et l'associe à la requête envoyée à la cible. Le jeton JWS/JWT et ses revendications sont alors disponibles pour permettre aux services de backend d'appliquer d'autres traitements de sécurité.
Vérifier et extraire les revendications d'un JWS/JWT obtenu à partir des requêtes client entrantes, depuis les réponses de service cible, les réponses de stratégie d'appel de service ou d'autres sources. Pour un jeton JWS/JWT signé, Apigee utilise l'un des algorithmes RSA, ECDSA ou HMAC pour vérifier la signature, que le jeton JWS/JWT ait été généré par Apigee ou un tiers. Pour un jeton JWT chiffré, Apigee déchiffre le jeton JWT à l'aide de l'un des algorithmes de chiffrement JWA compatibles (voir IETF RFC 7518).
Décoder un jeton JWS/JWT. Le décodage est particulièrement utile lorsqu'il est utilisé conjointement avec la règle de vérification JWS/JWT, dans les cas où la valeur d'une revendication (JWT) ou d'un en-tête (JWS/JWT) dans le JWS/JWT doit être connue avant de vérifier un jeton JWS/JWT signé ou de déchiffrer un jeton JWT chiffré.

Composantes d'un JWS/JWT

Un jeton JWS/JWT signé encode les informations en trois parties séparées par des points :

Header.Payload.Signature

La règle de génération JWS/JWT crée les trois parties.
La règle de vérification JWS/JWT examine les trois parties.
La règle DecodeJWS n'examine que l'en-tête. La règle DecodeJWT n'examine que l'en-tête et la charge utile.

Un JWS accepte également un format dissocié qui omet la charge utile du JWS :

Header..Signature

Dans le cas d'un JWS dissocié, la charge utile est envoyée séparément du JWS. Vous utilisez l'élément <DetachedContent> de la règle de vérification JWS pour spécifier la charge utile JWS brute non codée. La règle de vérification JWS vérifie ensuite le JWS en utilisant l'en-tête et la signature du jeton JWS et la charge utile spécifiée par l'élément <DetachedContent>.

Un jeton JWT chiffré encode les informations en cinq parties séparées par des points:

Header.Key.InitializationVector.Payload.AuthenticationTag

Les règles GenerateJWT et VerifyJWT créent ou examinent toutes ces parties. Le jeton DecodeJWT ne peut examiner que l'en-tête non chiffré.

Pour en savoir plus sur les jetons et leur encodage, leur signature ou leur chiffrement, consultez la documentation de référence correspondante:

JWT : IETF RFC7519
JWS : IETF RFC7515

Différences entre JWS et JWT

Vous pouvez utiliser un jeton JWT ou JWS pour partager des revendications ou des assertions entre des applications connectées. La principale différence entre les deux est la représentation de la charge utile :

JWT
- La charge utile est toujours un objet JSON.
- La charge utile est toujours associée au jeton JWT.
- L'en-tête typ du jeton est toujours défini sur JWT.
- La charge utile peut être signée ou chiffrée.
JWS
- La charge utile peut être représentée par n'importe quel format, tel qu'un objet JSON, un flux d'octets, etc.
- La charge utile n'a pas besoin d'être associée au JWS.
- L'en-tête et la charge utile sont toujours signés. JWS n'est pas compatible avec le chiffrement.

Comme le format JWT utilise toujours un objet JSON pour représenter la charge utile, les règles Apigee de génération JWT et de vérification JWT disposent d'une assistance intégrée pour gérer les noms de revendications enregistrés courants, tels que aud. iss, sub et d'autres. Cela signifie que vous pouvez utiliser des éléments de la règle de génération JWT pour définir ces revendications dans la charge utile, et des éléments de la règle de vérification JWT pour vérifier leurs valeurs. Consultez la section Noms de revendications enregistrés de la spécification JWT pour en savoir plus.

Outre la prise en charge de certains noms de revendications enregistrés, la règle GenerateJWT permet d'ajouter directement des revendications avec des noms arbitraires à la charge utile ou à l'en-tête du jeton JWT. Chaque revendication est une simple paire nom/valeur, dont la valeur peut être de type number, boolean, string, map ou array.

Lorsque vous utilisez GenerateJWS, vous fournissez une variable de contexte qui représente la charge utile. Étant donné qu'un JWS peut utiliser n'importe quelle représentation de données pour la charge utile, il n'existe aucun concept de "revendication de charge utile" dans un JWS. La règle GenerateJWS ne permet pas d'ajouter des revendications avec des noms arbitraires à la charge utile. Il est possible d'utiliser la règle GenerateJWS pour ajouter des revendications avec des noms arbitraires à l'en-tête du jeton JWS. En outre, les règles JWS acceptent une charge utile dissociée, où le JWS omet la charge utile. Une charge utile dissociée vous permet d'envoyer séparément le JWS et la charge utile. L'utilisation d'une charge utile dissociée peut être plus économe en espace, en particulier pour les charges utiles volumineuses. Elle est requise par plusieurs normes de sécurité.

Signature et chiffrement

Apigee peut générer un jeton JWT signé ou chiffré. Choisissez un jeton JWT signé lorsque la charge utile n'a pas besoin d'être secrète, mais qu'il est important de fournir des garanties d'intégrité et de non-répudiation aux lecteurs. Un jeton JWT signé garantit aux lecteurs que la charge utile n'a pas été modifiée depuis qu'il a été signé, et que celui-ci a été signé par le détenteur de la clé privée. Choisissez le jeton JWT chiffré lorsque la charge utile doit être secrète. Un jeton JWT chiffré assure la confidentialité de la charge utile, car seul le détenteur de la clé approprié peut la déchiffrer.

Il est possible d'utiliser à la fois un jeton JWT chiffré et signé, en particulier lorsque le jeton JWT chiffré utilise un algorithme de cryptographie asymétrique (RSA, ECDSA). Dans ce cas, l'identité du producteur de ce jeton JWT ne peut pas être déterminée, car la clé de chiffrement est publique. Pour résoudre ce problème, associez la signature au chiffrement. Voici un modèle type:

Signer une charge utile pour produire un jeton JWS ou un jeton JWT signé.
Chiffrer le résultat signé pour produire un jeton JWT chiffré.

L'intégration d'une charge utile signée dans un jeton JWT chiffré à l'aide de cette approche offre des garanties de non-répudiation et de confidentialité. Les règles Apigee peuvent produire, décoder et vérifier de telles combinaisons.

Algorithmes de signature

Pour les JWT signés, les règles de validation JWS/JWT et de génération JWT/JWT sont compatibles avec les algorithmes RSA, RSASSA-PSS, ECDSA et HMAC, à l'aide de sommes de contrôle SHA2 avec une puissance de bits de 256, 384 ou 512. Les règles DecodeJWS et DecodeJWT fonctionnent quel que soit l'algorithme utilisé pour signer le jeton JWS/JWT.

Algorithmes HMAC

L'algorithme HMAC s'appuie sur une clé secrète partagée, appelée "clé secrète", pour créer la signature (également appelée signature JWS/JWT) et pour valider la signature.

La longueur minimale de la clé secrète dépend de la puissance en bits de l'algorithme :

HS256 : longueur de clé minimale de 32 octets
HS384 : longueur de clé minimale de 48 octets
HS512 : longueur de clé minimale de 64 octets

Algorithmes RSA

Les algorithmes RSA utilisent une paire de clés publique/privée pour la signature cryptographique. La spécification JWA utilise les noms RS256, RS384 et RS512 pour représenter ces options. Avec les signatures RSA, la partie signataire utilise une clé privée RSA pour signer le JWS/JWT et la partie de vérification utilise la clé publique RSA correspondante pour valider la signature sur le JWS/JWT. Aucune taille n'est requise pour la clé.

Algorithmes RSASSA-PSS

Les algorithmes RSASSA-PSS constituent une mise à jour des algorithmes RSA et utilisent les noms PS256, PS384 et PS512. À l'instar des variantes RS*, RSASSA-PSS utilise une paire de clés publique/privée RSA pour la signature cryptographique. Le format, le mécanisme et les limites de taille de la clé sont les mêmes que pour les algorithmes RS*.

Algorithmes ECDSA

L'ensemble d'algorithmes ECDSA (Elliptic Curve Digital Signature Algorithm) est un algorithme de cryptographie à courbe elliptique avec une courbe P-256, P-384 ou P-521. Lorsque vous utilisez des algorithmes ECDSA, l'algorithme détermine le type de clé publique et privée que vous devez spécifier :

Algorithme	Courbe	Configuration de la clé
ES256	P-256	Clé générée à partir de la courbe P-256 (également appelée secp256r1 ou prime256v1)
ES384	P-384	Clé générée à partir de la courbe P-384 (également appelée secp384r1)
ES512	P-521	Clé générée à partir de la courbe P-521 (également appelée "secp521r1")

Algorithmes de chiffrement

Lorsque vous utilisez GenerateJWT et VerifyJWT pour gérer un jeton JWT chiffré, les règles sont compatibles avec les algorithmes suivants:

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

Clés et représentations clés

Les normes JOSE, qui couvrent les JWS, les jetons JWT signés et chiffrés, etc., décrivent comment utiliser des clés cryptographiques pour signer ou chiffrer des informations. Les éléments de base de toute opération de chiffrement incluent l'algorithme et la clé. Chaque algorithme nécessite différents types de clés et, dans certains cas, des tailles de clé différentes.

Les algorithmes symétriques, tels que la famille HS* pour la signature ou l'algorithme A128KW pour le chiffrement, nécessitent des clés symétriques ou partagées: la même clé est utilisée pour la signature et la validation, ou la même clé est utilisée pour le chiffrement et le déchiffrement. Les algorithmes asymétriques, tels que les algorithmes RS*, PS* et ES* pour la signature ou les algorithmes ECDH* pour le chiffrement, utilisent des paires de clés. Il existe une clé publique et une clé privée, et elles sont mises en correspondance. Lors de la signature, le signataire utilise la clé privée pour signer, et n'importe quelle partie peut utiliser la clé publique pour valider la signature. Lors du chiffrement, le chiffreur utilise la clé publique pour le chiffrement, tandis que l'outil de déchiffrement utilise la clé privée pour le déchiffrement. Les clés publiques, comme leur nom l'indique, sont partageables publiquement et ne doivent pas être gardées secrètes.

Il existe différentes manières de sérialiser des clés cryptographiques au format texte. Les règles Apigee acceptent les clés sérialisées sous différentes formes: encodées au format PEM, au format JWKS ou, pour les clés partagées, encodées en UTF-8 ou en base64.

Format PEM

Pour les clés publiques ou privées, il est courant d'utiliser l'encodage PEM, défini dans le document IETF RFC 7468. Voici un exemple de clé privée représentée au format PEM:

Il existe des formats PEM similaires pour les clés publiques ou les clés privées chiffrées.

Format JWKS

Une clé Web JSON (JWK) est une structure de données JSON qui représente une clé cryptographique unique. Un jeu de clés Web JSON (JWKS) est une structure JSON qui représente un ensemble de JWK. Les JWK et JWKS sont décrites dans la RFC7517. Voir les exemples de JWKS dans l'Annexe A. Exemples de jeux de clés JSON Web

Les JWKS sont destinées à permettre à toute partie de représenter un ensemble de clés dans un format standard. Un cas d'utilisation clé consiste à partager des clés publiques de manière standard, via un point de terminaison HTTP qui fournit des données au format JWKS. Lorsqu'une entreprise ou un système qui génère un jeton JWS ou JWT signé, tel qu'un fournisseur d'identité, publie ses clés publiques, tout système ou application capable de lire les clés publiques peut valider les signatures générées par la partie signataire. À l'inverse, tout système ou application souhaitant chiffrer des données qui ne doivent être lues que par une partie ou une entreprise spécifique peut récupérer les clés publiques appartenant à cette partie ou à cette entreprise et générer un jeton JWT chiffré à cet effet.

La RFC7517 décrit les éléments de clé JWKS pour chaque type de clé, tels que RSA ou EC. Les éléments suivants doivent toujours être présents:

kty : type de clé, tel que RSA ou EC.
kid : ID de la clé Il peut s'agir de n'importe quelle valeur de chaîne unique arbitraire ; il ne doit pas y avoir de doublons dans un même jeu de clés. Si le jeton JWT entrant a un ID de clé présent dans l'ensemble de JWKS, la règle VerifyJWS ou VerifyJWT utilise la clé publique appropriée pour valider la signature JWS/JWT.

Voici des exemples d'éléments facultatifs et leurs valeurs :

alg : l'algorithme de la clé. Il doit correspondre à l'algorithme de signature dans JWS/JWT.
use: utilisation prévue de la clé. Les valeurs types sont "sig" pour la signature et la vérification, ou "enc" pour le chiffrement et le déchiffrement.

Les JWKS suivantes (récupérées à l'origine à partir de https://www.googleapis.com/oauth2/v3/certs, mais obsolètes pour l'instant) contiennent les éléments et les valeurs requis, et seraient utilisables par Apigee:

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

Spécifier des clés des règles JWS et JWT

Qu'il s'agisse de générer ou de valider un jeton JWS ou JWT, vous devez fournir une clé à utiliser dans les opérations de chiffrement.

Lors de la génération d'un jeton JWT signé, vous devez fournir une clé pouvant produire la signature.

Dans le cas d'un algorithme de signature RS*, PS* ou ES*, qui utilise des clés asymétriques, vous devez fournir la clé privée pour générer la signature.
Dans le cas d'un algorithme HS*, vous devez fournir la clé symétrique qui sera utilisée lors de la génération de la signature.

Lorsque vous validez un jeton JWS/JWT signé, vous devez fournir une clé pouvant valider la signature.

Dans le cas d'un algorithme de signature RS*, PS* ou ES*, vous devez fournir la clé publique associée à la clé privée utilisée initialement pour signer le jeton.
Dans le cas d'un algorithme HS*, vous devez fournir la même clé symétrique que celle utilisée pour signer le JWS ou le JWT.

Vous disposez de deux options pour fournir les clés aux règles JWS et JWT:

indiquer la valeur de la clé directement (généralement via une variable de contexte), ou
fournir la clé indirectement, via un kid et un JWKS. Vous pouvez spécifier les JWKS directement ou indirectement via une URL HTTP à laquelle Apigee peut récupérer les JWKS.

L'option d'URL JWKS n'est généralement utilisée qu'en tant que source de clés publiques utilisables avec des algorithmes asymétriques, car les URL JWKS sont généralement publiques.

Les exemples suivants montrent comment fournir des clés directement dans différents scénarios.

Générer un jeton JWT signé avec l'algorithme HS256 Dans ce cas, la clé requise est une clé symétrique. Cette règle fournit une variable de contexte contenant la clé secrète encodée 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>

Valider un jeton JWT signé avec l'algorithme HS256 Dans ce cas, la clé requise est une clé symétrique. Comme dans l'exemple ci-dessus, cette règle fournit une variable de contexte contenant la clé secrète encodée 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>

Valider un jeton JWT signé avec l'algorithme PS256. Dans ce cas, la clé requise est une clé RSA publique. Cette règle fournit une variable de contexte contenant la clé publique encodée au format PEM.

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

Générer un jeton JWT signé avec l'algorithme PS256 Dans ce cas, la clé requise est une clé privée RSA. Cette règle fournit une variable de contexte contenant la clé privée encodée au format PEM.

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

JWKS en tant que source de clé lors de la vérification d'un jeton JWS ou JWT signé

Lorsqu'un système ou une application génère un jeton JWS/JWT, le système ou l'application insère généralement un identifiant de clé (la revendication kid) dans l'en-tête JWS/JWT. La clé indique à tout lecteur de jeton JWS/JWT quelle clé est requise pour valider la signature sur le jeton JWS/JWT signé, ou pour déchiffrer le jeton JWT chiffré.

Supposons, par exemple, qu'un émetteur signe un jeton JWT avec une clé privée. "ID de clé" identifie la clé publique correspondante qui doit être utilisée pour vérifier le jeton JWT. La liste des clés publiques est généralement disponible à un point de terminaison bien connu, tel que le point de terminaison Google Identity ou le point de terminaison Firebase Authentication. Les autres fournisseurs possèdent leurs propres points de terminaison publics qui publient des clés au format JWKS.

Lorsque vous utilisez Apigee pour valider un jeton JWS ou un jeton JWT signé avec des clés publiques partagées via un point de terminaison JWKS, vous disposez de plusieurs options:

Option 1: dans la configuration de la règle, spécifiez l'URI du point de terminaison JWKS dans l'élément <PublicKey/JWKS>. Par exemple, pour la règle de vérification JWT :
```
<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>
```
Dans ce cas, Apigee va:
1. Examinez l'en-tête JWS/JWT pour trouver l'algorithme de signature (alg), tel que RS256, et refusez le jeton JWT entrant si cet algorithme ne correspond pas à l'algorithme configuré dans la règle.
2. Récupérer la liste des clés avec leurs ID depuis le point de terminaison JWKS spécifié ou à partir d'un cache interne si ce point de terminaison JWKS a déjà été utilisé.
3. Examinez l'en-tête JWS/JWT pour trouver l'ID de clé (kid). Si le jeton JWT entrant n'inclut pas d'ID de clé (kid) dans l'en-tête, le mappage de l'enfant sur la clé de validation n'est pas possible, et Apigee génère une erreur.
4. Extrayez du JWKS le JWK avec l'ID de clé indiqué dans l'en-tête JWS/JWT. Générez une erreur si aucune clé portant cet ID n'est présente.
5. Vérifiez que l'algorithme de la JWK correspond à l'algorithme spécifié dans la configuration de la règle. Refusez la validation et générez une erreur si les algorithmes ne correspondent pas.
6. Utilisez cette clé publique pour valider la signature sur le JWS/JWT. Refusez la validation et générez une erreur si la signature ne s'est pas validée.
Option 2: dans la configuration de la règle, spécifiez une variable contenant l'URI du point de terminaison JWKS dans l'élément <PublicKey/JWKS>.

Par exemple, pour la règle de vérification JWT :
```
<VerifyJWT name="JWT-Verify-RS256">
  <Algorithm>RS256</Algorithm>
  <Source>json.jwt</Source>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <PublicKey>
    <JWKS uriRef="variable-containing-a-uri"/>
  </PublicKey>
  . . .
</VerifyJWT>
```
Dans ce cas, Apigee effectue les mêmes étapes que ci-dessus, sauf qu'Apigee récupère les JWKS non à partir d'un URI codé en dur, mais de l'URI spécifié dans la variable référencée par l'attribut uriRef. La mise en cache s'applique toujours.

Remarque: Soyez prudent lorsque vous utilisez l'attribut uriRef. En tant que concepteur du proxy, vous devez vous assurer que vous ne configurez pas vos règles de validation pour approuver les URI non validés. Par exemple, ce serait une pratique non sécurisée si vous décodez le JWS ou le JWT entrant, extrayez un URI JWKS de l'en-tête, puis vérifiez le JWS ou le JWT à partir de cet URI, sans vérifier au préalable que le L'URI figure sur une liste de confiance.
Option 3: dans la configuration de la règle, spécifiez une variable contenant les données JWKS codées en dur dans l'élément <PublicKey/JWKS>.

Par exemple, pour la règle de vérification JWT :
```
<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>
```
Dans ce cas, Apigee effectue les mêmes étapes que ci-dessus, sauf qu'il récupère les JWKS non à partir d'un URI, mais à partir de la variable de contexte que vous spécifiez dans l'attribut ref. En règle générale, vous auriez chargé cette variable de contexte à partir d'un ServiceCallout, d'un KVM ou d'un fichier de propriétés associé au proxy.

Remarque : Si vous utilisez un ServiceCallout pour récupérer le JWKS, il est recommandé de mettre en cache le JWKS pour éviter d'exécuter le ServiceCallout à chaque requête.

JWKS en tant que source de clé lors de la génération d'un jeton JWT chiffré

Lorsque vous générez un jeton JWT chiffré via un algorithme asymétrique (RSA-OAEP-256 ou l'une des variantes ECDH-*), vous effectuez le chiffrement à l'aide de la clé publique. Vous disposez de plusieurs options pour fournir la clé à la règle GenerateJWT

Une approche type consiste à spécifier dans la configuration de la règle l'URI du point de terminaison JWKS dans l'élément <PublicKey/JWKS>. Exemple :

<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>

Dans ce cas, Apigee va:

Assemblez la charge utile et l'en-tête non encodés du jeton JWT en fonction de la configuration de la règle.
Récupérez la liste des clés avec leurs ID depuis le point de terminaison JWKS spécifié ou à partir d'un cache interne si ce point de terminaison JWKS a déjà été utilisé. Actuellement, la valeur TTL du cache est de 5 minutes.
Extrayez le JWK avec l'ID de clé indiqué dans l'élément PublicKey/Id du JWKS. Générez une erreur si aucune clé portant cet ID n'est présente.
Vérifiez que l'algorithme de la JWK correspond à l'algorithme spécifié dans la configuration de la règle. Générez une erreur si les algorithmes ne correspondent pas.
Générez une séquence aléatoire à utiliser comme clé de chiffrement du contenu.
Utilisez la clé publique sélectionnée pour chiffrer la clé de chiffrement du contenu.
Utilisez la clé de chiffrement de contenu pour chiffrer la charge utile.
Enfin, assemblez toutes les parties dans un jeton JWT chiffré sérialisé.

Vous pouvez également utiliser l'attribut uriRef pour spécifier une variable contenant l'URI d'un point de terminaison JWKS. Exemple :

<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>

Dans ce cas, Apigee effectue les mêmes étapes que ci-dessus, sauf qu'il récupère les JWKS à partir de l'URI spécifié dans la variable référencée par l'attribut uriRef, au lieu d'un URI codé en dur. Apigee lit les JWKS à partir d'un cache interne si ce point de terminaison JWKS a déjà été utilisé.