You can follow this configuration with the built-in policies.
Verify an encrypted JWT
<VerifyJWT name="VJWT-1">
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
<Source>request.formparam.input</Source>
<!-- specify the key-encryption algorithm, at a minimum -->
<Algorithms>
<Key>RSA-OAEP-256</Key>
</Algorithms>
<!-- specify the private key when verifying an RSA-encrypted JWT -->
<PrivateKey>
<Value ref="private.rsa_privatekey"/>
</PrivateKey>
<!--
Additional configuration elements here...
<Subject>subject1</Subject>
<Issuer>urn://apigee-JWT-policy-example</Issuer>
<Audience>audience-here</Audience>
<AdditionalClaims> ... </AdditionalClaims>
-->
</VerifyJWT>
To generate an encrypted JWT
<GenerateJWT name="GJWT-1">
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
<!-- specify the key and content algorithms -->
<Algorithms>
<Key>RSA-OAEP-256</Key>
<Content>A128GCM</Content>
</Algorithms>
<!-- specify the public key to use for encryption -->
<PublicKey>
<Value ref="rsa_publickey"/>
</PublicKey>
<!-- any additional configuration elements you like -->
<AdditionalHeaders>
...
</AdditionalHeaders>
<Subject>subject1</Subject>
<Issuer>urn://apigee-JWT-policy-example</Issuer>
<Audience>audience-here</Audience>
<ExpiresIn>15m</ExpiresIn>
<AdditionalClaims>
...
</AdditionalClaims>
<OutputVariable>generated</OutputVariable>
</GenerateJWT>
The main difference in configuration for encrypted JWT is the use of the Algorithms element, in place of the "Algorithm" element that is used for signed JWT. In encrypted JWT, there are two algorithms of concern, the key-encryption algorithm, and the content-encryption-algorithm. All encrypted JWT use a symmetric algorithm (one variant of AES) to encrypt the content, and they use either a symmetric or asymmetric algorithm to encrypt the key used for the content encryption.
The Key encryption algorithms supported are:
- 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
- dir
The supported content-encryption algorithms are:
- A128CBC-HS256
- A192CBC-HS384
- A256CBC-HS512
- A128GCM
- A192GCM
- A256GCM
You can find the definitions for all of the above in the JWA specification.
Also, be aware that with encrypted JWT, if you are using asymmetric keys for the Key-encryption algorithm, you use the public key for generation, and the private key for verification. For signed JWT using asymmetric algorithms, it's the reverse: use the private key for generation and the public key for verification.
The above examples just cover the RSA case. Elliptic Curve algorithms work the same way - just specify one of the ECDH algorithms, and the appropriate public or private key, in the same way you would for a signed JWT (except, remember, private key for verification, and public key for generation). The AES variants of the key-encryption algorithm require a SecretKey, specified the same way you would specify a key for an HMAC-signed JWT.
The PBES2 variants use password-based key derivation. For those you need to specify the key differently. Something like this:
<PasswordKey>
<Id>abcdefg</Id> <!-- optional -->
<Value ref="private.password"/>
<SaltLength>16</SaltLength> <-- optional. default: 8 -->
<PBKDF2Iterations>10001</PBKDF2Iterations> <!-- optional: default 10000 -->
</PasswordKey>
For a direct key (alg=dir), similarly, there is a new configuration element for the key:
<DirectKey>
<Id>A12345</Id> <!-- optional -->
<Value encoding="base16|hex|base64|base64url" ref="private.directkey"/>
</DirectKey>
The capability to generate and verify encrypted JWT should now be available in your Apigee organizations. Documentation for these new capabilities is coming.
LinkedIn
Twitter
