JWT Private/Public keys

[sunithabprasad]

In order to use the JWT policies/token,

1) does Apigee support the generation of private/public keys within the platform

2) for RS256, RS384, RS512 - does it have to be that both prrivate / public keys be in pkcs8 format

[dchiesa1]

1) no - you should generate keypairs on your own systems. Using openssl or some other tool.

2) yes, PKCS8.

(FYI, I believe this information is in the documentation for the policies. )

[sunithabprasad]

Thanks Dino.

1) If we generate the keypairs outside of Apigee platform, how can the key rotations be performed ?

2) on PKCS8 - is it only for private keys ?

i generate the private/public keys using openssl as below :

openssl rsa -in rsa_private.pem -pubout -out rsa_public.pem

openssl pkcs8 -topk8 -inform PEM -outform DER -in rsa_private.pem -nocrypt > rsa_private_pkcs8

Am trying to use the example proxy you have in the repo jwt-generate and jwt-verify(RS256-Basic):

the token created using the private key by jwt-generate-but trying to verify the token in the request as a 2nd step , using the public key i have - it fails with "FailedToDecode"

[dchiesa1]

1) If we generate the keypairs outside of Apigee platform, how can the key rotations be performed ?

One simple way to do it is... Store the private keys in the KVM. When you rotate keys, just update the KVM. This means you must precede the call to GenerateJWT with a call to KeyValueMapOperations to retrieve the private key. Probably you should use an encrypted KVM to store the private key. Then maybe you want to stand up a JWKS endpoint to serve the public keys. You could do that with Apigee Edge too, but it might be easier to just do it with a static file.

2) on PKCS8 - is it only for private keys ?

No. Both public and private keys should be encoded this way.

it fails with "FailedToDecode"

Which policy is leading to this error? If it is a JWT policy, then often there is an .error variable that provides more information. Look in trace to see if you can find this variable. If there is a failure in _decoding_ the JWT it is possible that the token you are trying decode is bogus or corrupted. Try decoding it in https://jwt.io or decode it manually yourself (split by dots then base64 decode the 3 parts).

[sunithabprasad]

The .error variable has - "The Token's signature resulted invalid when verified using the Algorithm SHA256withRSA

[sunithabprasad]

And this is with the jwt-verify policy - /jwt-verify/rs256/1 - the example proxy you had

[sunithabprasad]

keys generated using :

openssl rsa -in rsa_private.pem -pubout -out rsa_public.pem

openssl pkcs8 -topk8 -inform PEM -outform DER -in rsa_private.pem -nocrypt > rsa_private_pkcs8

Am trying to use the example proxy you have in the repo jwt-generate and jwt-verify(RS256-Basic):

[dchiesa1]

Am trying to use the example proxy you have in the repo jwt-generate

What repo?

[dchiesa1]

"The Token's signature resulted invalid when verified using the Algorithm SHA256withRSA"

This error means ... what it says. It means that the token you presented for verification cannot be verified with the given public key and RS256. Keep in mind that you need to provide the public key to the VerifyJWT policy. )

I don't think the message - "The Token's signature resulted invalid when verified using the Algorithm SHA256withRSA" - is telling you that "the public key cannot be deserialized". If you get this message and as a result are inclined to look into PEM formats, I think you're off the trail.

It seems to me that you are experiencing two or three different problems, and not distinguishing between them.

1. If the PEM format is wrong, somehow, the VerifyJWT policy will be unable to instantiate a public key, and will report that error to you, in the error variable. It will say something in English like "I cannot read a private key" or "Cannot read a private key from the policy configuration". Something like that.
2. If the inbound JWT is corrupted, then you could get a "Failed to decode" error. This means the thing presented to the policy as a JWT, is not well formed. Decoding is the process of splitting the JWT string and base64-decoding it. This happens before signature verification . It's the very first step. The VerifyJWT policy will try to decode first, an that effort can succeed whether or not you have a valid private key PEM. If it fails, you will see "Failed to decode". This says nothing about the PEM, or whether the signature is valid.
3. If the JWT is well formed (Decodable), and the PEM is readable, but the PEM represents a public key that is not matched with the private key used to sign the JWT, then you will receive "The Token's signature resulted invalid when verified using the Algorithm SHA256withRSA"