Cette page a été traduite par l'API Cloud Translation.

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 jeton JWT ou JWS signé, ou un jeton 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 dans 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 derniers 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 dans le JWT ou le JWS, et de prendre des décisions en fonction de ces revendications ou de propager ces informations aux services 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 JWS/JWT et ses revendications sont ensuite 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 JWS/JWT signé, Apigee utilise l'un des algorithmes RSA, ECDSA ou HMAC pour valider la signature, que le JWS/JWT ait été généré par Apigee ou par 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 la RFC 7518 de l'IETF).
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éeront ou examineront toutes ces parties. DecodeJWT ne peut examiner que l'en-tête non chiffré.

Pour en savoir plus sur les jetons, leur encodage, leur signature ou leur chiffrement, consultez les documents de normes pertinents:

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, et la règle GenerateJWS n'autorise pas l'ajout de revendications avec des noms arbitraires à la charge utile. Vous pouvez utiliser la règle GenerateJWS pour ajouter des revendications avec des noms arbitraires à l'en-tête du 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 efficace en termes d'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 des jetons JWT signés ou chiffrés. Choisissez un 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é assure aux lecteurs que la charge utile n'a pas changé depuis la signature du jeton JWT et que le jeton JWT a été signé par le titulaire de la clé privée. Choisissez un jeton JWT chiffré lorsque la charge utile doit être secrète. Un jeton JWT chiffré garantit la confidentialité de la charge utile, car seul le titulaire de la clé appropriée peut la déchiffrer.

Il est possible d'utiliser à la fois des jetons JWT chiffrés et signés, 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 JWT ne peut pas être déterminée, car la clé de chiffrement est publique. Pour résoudre ce problème, combinez la signature au chiffrement. Voici un exemple type:

Signez une charge utile pour générer un JWS ou un JWT signé.
Chiffrez le résultat signé pour générer un jeton JWT chiffré.

L'intégration d'une charge utile signée dans un jeton JWT chiffré à l'aide de cette approche offre à la fois des garanties de non-répudiation et de confidentialité. Les règles Apigee peuvent produire, décoder et valider 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 sont une mise à jour des algorithmes RSA et utilisent les noms PS256, PS384 et PS512. Comme les 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 les jetons JWT chiffrés, 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 de 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 fondamentaux de toute opération de cryptographie incluent l'algorithme et la clé. Les différents algorithmes nécessitent différents types de clés et, dans certains cas, différentes tailles de clés.

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, l'outil de chiffrement utilise la clé publique pour chiffrer, et le déchiffreur utilise la clé privée pour déchiffrer. Comme leur nom l'indique, les clés publiques peuvent être partagées 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: format PEM, format JWKS ou, pour les clés partagées, format UTF-8 ou base64.

Format PEM

Pour les clés publiques ou privées, il est courant d'utiliser l'encodage PEM, défini dans la norme 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 seule clé cryptographique. Un jeu de clés Web JSON (JWKS) est une structure JSON qui représente un ensemble de clés JWK. Les JWK et JWKS sont décrites dans la RFC7517. Consultez les exemples de JWKS en annexe A. Exemples de jeux de clés JSON Web

Le format JWKS est destiné à permettre à toute partie de représenter un ensemble de clés dans un format standard. Un cas d'utilisation clé est le partage de 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 des jetons JWS ou JWT signés, comme un fournisseur d'identité, publie ses clés publiques, tout système ou application capable de lire les clés publiques peut vérifier 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. Ces éléments doivent toujours être présents:

kty : type de clé, tel que RSA ou EC.
kid : ID de 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 typiques sont "sig" pour la signature et la validation, ou "enc" pour le chiffrement et le déchiffrement.

La JWKS suivante (initialement récupérée sur https://www.googleapis.com/oauth2/v3/certs, mais obsolète à présent) inclut les éléments et les valeurs requis et peut être utilisée 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 pour les 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 à l'origine 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 les récupérer.

L'option d'URL JWKS n'est généralement utilisée que comme 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>

Utiliser un JWKS comme source de clé lors de la validation d'un JWS ou d'un jeton JWT signé

Lorsqu'un système ou une application génère un JWS/JWT, il insère généralement un identifiant de clé (la revendication kid) dans l'en-tête JWS/JWT. La clé indique à tout lecteur du JWS/JWT la clé requise pour valider la signature sur le JWS/JWT signé ou 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 à utiliser pour valider 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. D'autres fournisseurs disposent de leurs propres points de terminaison publics qui publient des clés au format JWKS.

Lorsque vous utilisez Apigee pour valider un JWS ou un jeton JWT signé avec des clés publiques partagées via un point de terminaison JWKS, vous avez 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:
1. Examinez l'en-tête JWS/JWT pour trouver l'algorithme de signature (alg), tel que RS256, et rejetez le jeton JWT entrant si cet algorithme ne correspond pas à celui configuré dans la règle.
2. 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é.
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, il est impossible de mapper kid à la clé de validation, 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ère une erreur si une clé avec cet ID de clé n'est pas présente.
5. Vérifiez que l'algorithme du JWK correspond à celui 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 de proxy, vous devez vous assurer de ne pas configurer vos règles de validation pour faire confiance aux URI non vérifié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 qui contient 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 avez 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 les JWKS, il est recommandé de les mettre en cache 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é à l'aide d'un algorithme asymétrique (RSA-OAEP-256 ou l'une des variantes ECDH-*), vous utilisez la clé publique pour le chiffrement. Vous disposez d'options pour fournir la clé à la règle GenerateJWT.

Une approche courante 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:

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 cinq minutes.
Extrayez du JWKS le JWK avec l'ID de clé indiqué dans l'élément PublicKey/Id. Génère une erreur si une clé avec cet ID de clé n'est pas présente.
Vérifiez que l'algorithme du 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 du 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 le JWKS à partir d'un cache interne si ce point de terminaison JWKS a déjà été utilisé.