Panoramica dei criteri JWS e JWT

Questa pagina si applica a Apigee e Apigee ibridi.

Visualizza documentazione di Apigee Edge.

Questo argomento fornisce informazioni generali sul token JWT (JSON Web Token) e JWS (JSON Web Signature) e i criteri Apigee JWS/JWT che potrebbero interessare gli sviluppatori di proxy Apigee.

Introduzione

Sia JWS che JWT sono comunemente utilizzati per condividere rivendicazioni o asserzioni tra diverse applicazioni. I criteri JWS/JWT consentono ai proxy API Apigee di:

  • Genera un JWT firmato o JWS o JWT criptato.
  • Verifica un JWT firmato. o un JWS, oppure un JWT criptato e verificare alle rivendicazioni selezionate all'interno del JWS/JWT.
  • Decodificare un JWT firmato o criptato o un JWS senza convalidare la firma o decriptare i JWT o JWS criptati. Nel caso di un JWS, il criterio DecodeJWS può decodificare solo le attestazioni in l'intestazione del JWS. Nel caso di un JWT criptato, il criterio DecodeJWT può decodificare solo l'intestazione non criptata.

Negli ultimi due casi, il criterio imposta anche le variabili di flusso. Ciò consente ai criteri successivi nel flusso Apigee di esaminare le attestazioni nel JWT o JWS e di prendere decisioni in base a queste richieste o per propagare le informazioni ai servizi di backend.

Quando utilizzi i criteri VerifyJWS o VerifyJWT, i valori JWS/JWT non validi vengono rifiutati e comporteranno un errore . Analogamente, quando si utilizzano i criteri DecodeJWS o DecodeJWT, un formato JWS/JWT in un formato non corretto genererà un errore. .

Video

Guarda un breve video per una rapida introduzione a JWT. Mentre il video è specifici per la generazione di un JWT, molti dei concetti sono gli stessi per JWS.

Un breve video per scoprire di più sulla struttura JWT.

Casi d'uso

Puoi utilizzare i criteri JWS/JWT per:

  • Genera un nuovo JWS/JWT sul lato del proxy o dell'endpoint di destinazione di un proxy Apigee. Per Ad esempio, potresti creare un flusso di richieste proxy che genera un JWS/JWT e lo restituisce a un client. In alternativa, potresti progettare un proxy in modo che generi un JWS/JWT nel flusso di richieste di destinazione. lo allega alla richiesta inviata alla destinazione. Il JWS/JWT e le sue affermazioni saranno quindi per abilitare i servizi di backend in modo da applicare ulteriori elaborazioni di sicurezza.
  • Verificare ed estrarre le attestazioni da un JWS/JWT ottenuti dalle richieste del client in entrata, dalla destinazione di servizio, dalle risposte ai criteri relativi ai callout del servizio o da altre origini. Per una JWS/JWT, Apigee utilizzerà uno degli algoritmi RSA, ECDSA o HMAC per verificare la firma. se i JWS/JWT sono stati generati da Apigee o da terze parti. Per un JWT criptato, Apigee decriptare il JWT, utilizzando uno degli algoritmi di crittografia JWA supportati (vedi IETF RFC 7518).
  • Decodifica un JWS/JWT. La decodifica è utile soprattutto se utilizzata insieme alle Verifica JWS/JWT nei casi in cui il valore di una dichiarazione (JWT) o di un'intestazione (JWS/JWT) all'interno del devono essere note prima di verificare un JWS/JWT firmato o di decriptare un JWT criptato.

Parti di un JWS/JWT

Un JWS/JWT firmato codifica le informazioni in tre parti separate da punti:

Header.Payload.Signature
  • Il criterio Genera JWS/JWT crea tutte e tre le parti.
  • Il criterio Verifica JWS/JWT esamina tutte e tre le parti.
  • Il criterio DecodeJWS esamina solo l'intestazione. Il criterio DecodeJWT esamina solo l'intestazione e il payload.

Un JWS supporta anche un modulo scollegato che omette il payload dal JWS:

Header..Signature

Con un JWS scollegato, il payload viene inviato separatamente dal JWS. Puoi utilizzare Elemento <DetachedContent> del criterio di verifica JWS per specificare il payload JWS non elaborato e non codificato. Il criterio Verifica JWS verifica quindi il JWS utilizzando l'intestazione e la firma al suo interno e nel payload specificato dall'elemento <DetachedContent>.

Un JWT criptato codifica le informazioni in cinque parti separate da punti:

Header.Key.InitializationVector.Payload.AuthenticationTag

I criteri CreateJWT e VerifyJWT creeranno o esamineranno tutte queste parti. DecodeJWT può esaminare solo l'intestazione non criptata.

Per ulteriori informazioni sui token e su come vengono codificati, firmati o criptati, consulta le documenti standard:

Differenze tra JWS e JWT

Puoi utilizzare un JWT o un JWS per condividere rivendicazioni o asserzioni tra le applicazioni collegate. La principale differenza tra i due è la rappresentazione del payload:

  • JWT
      .
    • Il payload è sempre un oggetto JSON.
    • Il payload è sempre collegato al JWT.
    • L'intestazione typ del token è sempre impostata su JWT.
    • Il payload può essere firmato o criptato.
  • JWS
      .
    • Il payload può essere rappresentato da qualsiasi formato, ad esempio un oggetto JSON, un flusso di byte, un flusso di ottetti e altri.
    • Il payload non deve essere collegato al JWS.
    • L’intestazione e il payload sono sempre firmati. JWS non supporta la crittografia.

Poiché il formato JWT utilizza sempre un oggetto JSON per rappresentare il payload, Apigee I criteri GeneraJWT e VerifyJWT hanno integrato il supporto per gestire le attestazioni registrate comuni Nomi, ad esempio aud, iss, sub e altri. Ciò significa che è possibile utilizzare elementi del criterio CreateJWT per impostare queste attestazioni nel ed elementi del criterio VerifyJWT per verificarne i valori. Consulta il reclamo registrato Sezione Nomi della specifica JWT per saperne di più.

Oltre a supportare determinati nomi di dichiarazioni registrate, il criterio GeneraJWT direttamente supporta l'aggiunta di attestazioni con nomi arbitrari al payload o all'intestazione del JWT. Ogni rivendicazione viene una semplice coppia nome/valore, in cui il valore può essere di tipo number, boolean, string, map o array.

Quando utilizzi GeneraJWS, fornisci una variabile di contesto che rappresenta il payload. Poiché un JWS può utilizzare qualsiasi rappresentazione dei dati per il payload, non esiste il concetto di "rivendicazione del payload" nel JWS e il criterio CreateJWS non supporta l'aggiunta di attestazioni con nomi arbitrari all'istanza per il payload. È possibile utilizzare il criterio CreateJWS per aggiungere attestazioni con nomi arbitrari a l'intestazione del JWS. Inoltre, i criteri JWS supportano un payload scollegato, in cui JWS omette il payload. Un payload scollegato ti consente di inviare JWS e payload separatamente. Utilizzo può essere più efficiente in termini di spazio, soprattutto per payload di grandi dimensioni, ed è secondo diversi standard di sicurezza.

Firma e crittografia

Apigee può generare un JWT firmato o criptato. Scegli il JWT firmato quando non è necessario che il payload sia ma è importante fornire ai lettori garanzie di integrità e non ripudio. Un JWT firmato assicura ai lettori che il payload non sia cambiato da quando il JWT è stato firmato e che il JWT sia stato firmato dal titolare della chiave privata. Scegli JWT criptato quando il payload deve essere il secret. Un JWT criptato fornisce riservatezza per il payload, in quanto solo la chiave appropriata proprietario può decriptarlo.

È possibile utilizzare JWT sia criptato che firmato insieme, soprattutto quando JWT utilizza un algoritmo di crittografia asimmetrica (RSA, ECDSA). In questo caso, l'identità impossibile determinare il produttore di quel JWT perché la chiave di crittografia è pubblica. Per risolvere il problema, combina firma e crittografia. Un pattern tipico è il seguente:

  • Firma un payload per produrre un JWS o un JWT firmato.
  • Cripta il risultato firmato per produrre un JWT criptato.

L'incorporamento di un payload firmato all'interno di un JWT criptato utilizzando questo approccio fornisce sia garanzie di non ripudio e riservatezza. I criteri di Apigee possono generare e decodificare verificare queste combinazioni.

Algoritmi di firma

Per il JWT firmato, i criteri di verifica JWS/JWT e di generazione JWS/JWT supportano RSA, Algoritmi RSASSA-PSS, ECDSA e HMAC che utilizzano checksum SHA2 con intensità di bit 256, 384 o 512. I criteri DecodeJWS e DecodeJWT funzionano indipendentemente dall'algoritmo utilizzato per firmare il JWS/JWT.

Algoritmi HMAC

Gli algoritmi HMAC si basano su un secret condiviso, noto come chiave segreta, per la creazione (nota anche come firma del JWS/JWT) e della verifica della firma.

La lunghezza minima della chiave segreta dipende dalla forza in bit dell'algoritmo:

  • HS256: lunghezza minima della chiave di 32 byte
  • HS384: lunghezza minima della chiave di 48 byte
  • HS512: lunghezza minima della chiave di 64 byte

Algoritmi RSA

Gli algoritmi RSA utilizzano una coppia di chiave pubblica/privata per la firma crittografica. JWA utilizza le sigle RS256, RS384 e RS512 per rappresentare queste opzioni. Con RSA firme, la parte che firma utilizza una chiave privata RSA per firmare il JWS/JWT e la verifica utilizzi la chiave pubblica RSA corrispondente per verificare la firma sul JWS/JWT. Non sono presenti requisiti di dimensione delle chiavi.

Algoritmi RSASSA-PSS

Gli algoritmi RSASSA-PSS sono un aggiornamento degli algoritmi RSA e usano il nickname PS256, PS384 e PS512. Come le varianti RS*, RSASSA-PSS utilizza una coppia di chiave pubblica/privata RSA per la firma crittografica. Il formato, il meccanismo e i limiti di dimensione della chiave sono gli stessi di per gli algoritmi RS*.

Algoritmi ECDSA

Il set di algoritmi Elliptic Curve Digital Signature Algorithm (ECDSA) viene algoritmi di crittografia ellittica con curve P-256, P-384 o P-521. Quando utilizzi l'ECDSA algoritmi, l'algoritmo determina il tipo di chiave pubblica e privata che devi specificare:

Algoritmo Curva Requisito chiave
ES256 P-256 Una chiave generata dalla curva P-256 (nota anche come secp256r1 o prime256v1)
ES384 P-384 Una chiave generata dalla curva P-384 (nota anche come secp384r1)
ES512 P-521 Una chiave generata dalla curva P-521 (nota anche come secp521r1)

Algoritmi di crittografia

Quando usi GeneraJWT e VerifyJWT per gestire JWT criptato, i criteri supportano questi algoritmi:

  • 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

Chiavi e rappresentazioni chiave

Gli standard JOSE, relativi a JWS, JWT firmato e criptato, e altri ancora, descrivono come utilizzare chiavi di crittografia per firmare o crittografare le informazioni. Gli elementi fondamentali per qualsiasi l'operazione crittografica include l'algoritmo e la chiave. Algoritmi diversi richiedono tipi di chiavi diversi e, in alcuni casi, dimensioni delle chiavi diverse.

Algoritmi simmetrici, come la famiglia HS* per la firma o l'algoritmo A128KW per crittografia, richiedono chiavi simmetriche o condivise: la stessa chiave viene utilizzata per la firma verifica o per la crittografia e la decriptazione viene utilizzata la stessa chiave. Algoritmi asimmetrici, come gli algoritmi RS*, PS* ed ES* per la firma o gli algoritmi ECDH* per la crittografia, utilizzare coppie di chiavi: esistono una chiave pubblica e una chiave privata corrispondente. Durante la firma, il firmatario utilizza la chiave privata per la firma e chiunque può utilizzare il chiave pubblica per verificare la firma. Durante la crittografia, l'utente utilizza la chiave pubblica per e l'utilità di decrittografia utilizza la chiave privata per decriptare. Chiavi pubbliche, come nome suggeriscono, sono condivisibili pubblicamente e non devono essere tenuti segreti.

Esistono diversi modi per serializzare le chiavi di crittografia in formato testo. Criteri di Apigee accettare chiavi serializzate in varie forme: con codifica PEM, JWKS o per chiavi condivise, Formato con codifica UTF-8 o Base64.

Formato PEM

Per le chiavi pubbliche o private, è comune utilizzare la codifica PEM, definita in IETF RFC 7468. Ecco un esempio di una chiave privata rappresentata in formato PEM: 

-----BEGIN PRIVATE KEY-----
MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgVcB/UNPxalR9zDYAjQIf
jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK
H0M6xpM2q+53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ
-----END PRIVATE KEY-----

Esistono formati PEM simili per le chiavi pubbliche o per chiavi private criptate.

Formato JWKS

Una chiave web JSON (JWK) è una struttura di dati JSON che rappresenta una singola chiave di crittografia. R Il set di chiavi web JSON (JWKS) è una struttura JSON che rappresenta un insieme di JWK. JWK e JWKS sono descritto in RFC7517. Consulta Esempi di JWKS nell'Appendice A. Chiave web JSON di esempio Set.

JWKS è pensato per consentire a qualsiasi parte di rappresentare un set di chiavi in un formato standard. Una chiave è la condivisione delle chiavi pubbliche in modo standard, tramite un endpoint HTTP che in formato JWKS. Quando una società o un sistema che genera JWS o JWT firmato, ad esempio un Identity Provider, pubblica le proprie chiavi pubbliche, qualsiasi sistema o applicazione in grado di leggere chiavi pubbliche, possono verificare le firme generate dalla parte che firma. Al contrario, qualsiasi sistema che vuole criptare dati che dovrebbero essere letti solo da una determinata parte o azienda; recuperare le chiavi pubbliche appartenenti a quella parte o azienda e a generare JWT per questo scopo.

RFC7517 descrive il modello JWKS elementi chiave per ogni tipo di chiave, ad esempio RSA o EC. Questi elementi devono essere sempre presenti:

  • kty - Il tipo di chiave, ad esempio RSA o EC.
  • kid: l'ID chiave. Può essere qualsiasi valore di stringa univoco arbitrario. lì non devono essere duplicati all'interno di un singolo set di chiavi. Se il JWT in entrata ha un ID chiave che nel set di JWKS, il criterio VerifyJWS o VerifyJWT utilizzerà il corretto per verificare la firma JWS/JWT.

Di seguito sono riportati alcuni esempi di elementi facoltativi e dei relativi valori:

  • alg: l'algoritmo chiave. Deve corrispondere all'algoritmo di firma nel JWS/JWT.
  • use: l'uso previsto della chiave. I valori tipici sono "sig" per la firma e la verifica, o "enc" per la crittografia e la decrittografia.

Il seguente JWKS (originariamente recuperato da https://www.googleapis.com/oauth2/v3/certs, ma ora non aggiornato) include gli elementi e i valori richiesti e che sarebbero utilizzabili da 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",
        }
     ]
  }

Specifica delle chiavi per i criteri JWS e JWT

Che tu stia generando o verificando JWS o JWT, devi fornire una chiave da utilizzare all'interno le operazioni crittografiche.

Quando generi un JWT firmato, devi fornire una chiave in grado di riprodurre il token firma.

  • Nel caso di un algoritmo di firma RS*, PS* o ES*, che utilizza chiavi asimmetriche, deve fornire la chiave privata per generare la firma.
  • Nel caso di un algoritmo HS*, è necessario fornire la chiave simmetrica che verrà utilizzata quando generi la firma.

Quando verifichi un JWS/JWT firmato, devi fornire una chiave che possa verificare il firma.

  • Nel caso di un algoritmo di firma RS*, PS* o ES*, è necessario Indicare la chiave pubblica associata alla chiave privata utilizzata originariamente per firmare il token.
  • Nel caso di un algoritmo HS*, devi fornire la stessa chiave simmetrica che hai utilizzato per firmare il JWS o il JWT.

Hai a disposizione due opzioni per fornendo le chiavi per i criteri JWS e JWT:

  • Fornisci direttamente il valore chiave (in genere tramite una variabile di contesto) oppure
  • Fornisci la chiave indirettamente, tramite kid e JWKS. Puoi specificare il valore direttamente o indirettamente tramite un URL http da cui Apigee può recuperare il JWKS.

L'opzione URL JWKS viene generalmente utilizzata solo come fonte di chiavi pubbliche utilizzabili con algoritmi asimmetrici, perché gli URL JWKS di solito sono pubblici.

I seguenti esempi illustrano alcuni modi per fornire le chiavi direttamente in vari scenari.

  • Genera un JWT firmato con l'algoritmo HS256. Il campo obbligatorio in questo caso è una chiave simmetrica. Questo criterio fornisce una variabile di contesto che contiene la chiave segreta codificata in 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 firmato con l'algoritmo HS256. La chiave richiesta in questo caso è simmetrica chiave. Come nell'esempio precedente, questo criterio fornisce una variabile di contesto che contiene la chiave segreta codificata in 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 che è stato firmato con l'algoritmo PS256. La chiave richiesta in questo caso è una chiave RSA pubblica. Questo criterio fornisce una variabile di contesto che contiene la codifica PEM chiave pubblica.

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

  • Generare un JWT firmato con l'algoritmo PS256. In questo caso, la chiave richiesta è una chiave privata chiave RSA. Questo criterio fornisce una variabile di contesto che contiene la chiave privata con codifica PEM. 

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

JWKS come origine della chiave durante la verifica di un JWS o di un JWT firmato

Quando un sistema o un'app genera un JWS/JWT, in genere l'app o il sistema inserisce una chiave Identificatore (la dichiarazione kid) nell'intestazione JWS/JWT. La chiave dice a qualsiasi lettore del JWS/JWT, la chiave necessaria per verificare la firma sul JWS/JWT firmato o per decriptare il JWT criptato.

Ad esempio, supponiamo che un emittente firmi un JWT con una chiave privata. L'"ID chiave" identifica chiave pubblica corrispondente che deve essere utilizzata per verificare il JWT. L'elenco delle chiavi pubbliche è in genere disponibili su alcuni endpoint noti, come Endpoint di Google Identity o l'endpoint di autenticazione di Firebase. Altri provider avranno i propri endpoint pubblici che pubblicano le chiavi in formato JWKS.

Quando usi Apigee per verificare un JWS o un JWT firmato con chiavi pubbliche condivise tramite un JWKS endpoint, hai alcune opzioni:

  • Opzione 1: nella configurazione dei criteri, specifica l'URI dell'endpoint JWKS nella l'elemento <PublicKey/JWKS>. Ad esempio, per il criterio 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>

    In questo caso, Apigee:

    1. Esaminare l’intestazione JWS/JWT per trovare l’algoritmo di firma (alg), ad esempio RS256, e rifiutare il JWT in entrata se questo algoritmo non corrisponde a quello configurato il criterio.
    2. Recupera l'elenco delle chiavi con i relativi ID dall'endpoint JWKS specificato o da un se questo endpoint JWKS è già stato utilizzato in precedenza.
    3. Esamina l'intestazione JWS/JWT per trovare l'ID chiave (bambino). Se il JWT in entrata non include un l'ID chiave (kid) nell'intestazione, non è quindi possibile associare l'ID bambino alla chiave di verifica. Apigee genererà un errore.
    4. Estrai il codice dal JWKS, ovvero il JWK con l'ID chiave indicato nell'intestazione JWS/JWT. Genera un errore se non è presente una chiave con quell'ID chiave.
    5. Verifica che l'algoritmo del JWK corrisponda a quello specificato nel criterio configurazione. Rifiuta la verifica e genera un errore se gli algoritmi non corrispondono.
    6. e utilizzala per verificare la firma nel file JWS/JWT. Rifiuta la verifica e genera un errore se la firma non viene verificata.

  • Opzione 2: nella configurazione dei criteri, specifica una variabile che contenga la URI dell'endpoint JWKS nell'elemento <PublicKey/JWKS>.

    Ad esempio, per il criterio 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>

    In questo caso, Apigee eseguirà gli stessi passaggi di cui sopra, ad eccezione del fatto che Apigee recupererà il JWKS non da un URI hardcoded, ma dall'URI specificato nella variabile a cui viene fatto riferimento dall'attributo uriRef. La memorizzazione nella cache continua a essere applicata.

  • Opzione 3: nella configurazione dei criteri, specifica una variabile che contenga la dati JWKS hardcoded nell'elemento <PublicKey/JWKS>.

    Ad esempio, per il criterio 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>

    In questo caso, Apigee eseguirà gli stessi passaggi di cui sopra, ad eccezione del fatto che Apigee recupererà il JWKS non da un URI, ma dalla variabile di contesto specificata l'attributo ref. Di solito si carica una variabile di contesto da un ServiceCallout, un KVM o un file delle proprietà associato al proxy.

JWKS come origine chiave durante la generazione di un JWT criptato

Quando si genera un JWT criptato tramite un algoritmo asimmetrico (RSA-OAEP-256 o uno qualsiasi ECDH-*) utilizzi la chiave pubblica per criptare. Hai a disposizione delle opzioni per fornendo la chiave per il criterioGenerateJWT

Un approccio tipico consiste nello specificare nella configurazione dei criteri l'URI dell'endpoint JWKS nella Elemento <PublicKey/JWKS>. Ad esempio:

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

In questo caso, Apigee:

  1. Assembla il payload non codificato e l'intestazione per il JWT in base alla configurazione del criterio.
  2. Recupera l'elenco delle chiavi con i relativi ID dall'endpoint JWKS specificato o da un indirizzo interno se questo endpoint JWKS è già stato utilizzato. Attualmente il TTL della cache è di 5 minuti.
  3. Estrai il JWK con l'ID chiave indicato in PublicKey/Id dal JWKS. Genera un errore se non è presente una chiave con quell'ID chiave.
  4. Verifica che l'algoritmo del JWK corrisponda a quello specificato nel criterio configurazione. Genera un errore se gli algoritmi non corrispondono.
  5. Genera una sequenza casuale da utilizzare come chiave di crittografia dei contenuti.
  6. Usa la chiave pubblica selezionata per criptare la chiave di crittografia dei contenuti.
  7. Utilizza la chiave di crittografia dei contenuti per criptare il payload.
  8. Infine, assembla tutte le parti in un JWT criptato serializzato.

Un'alternativa è utilizzare l'attributo uriRef per specificare una variabile che contiene l'URI di un endpoint JWKS. Ad esempio:

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

In questo caso, Apigee eseguirà gli stessi passaggi di cui sopra, ad eccezione del fatto che Apigee recupererà JWKS dall'URI specificato nella variabile a cui fa riferimento l'attributo uriRef, anziché un URI hardcoded. Apigee leggerà il JWKS da una sessione se questo endpoint JWKS è già stato utilizzato.