Get hands-on experience with 20+ free Google Cloud products and $300 in free credit for new customers.

ApigeeX - generate JWE error while using java callout (jar) for a signed JWT

Hi @dchiesa1 , We are seeing below error while we try to generate JWE for a signed payload. Is there anything that we are missing?

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<JavaCallout continueOnError="false" enabled="true" name="JC-GenerateJWE">
<DisplayName>JC-GenerateJWE</DisplayName>
<Properties>
<Property name="key-encryption">RSA-OAEP-256</Property>
<Property name="content-encryption">A256GCM</Property>
<Property name="payload">{signed_payload}</Property>
<Property name="expiry">1h</Property>
<!-- the context variable "my_public_key" must hold a PEM-encoded RSA public key -->
<Property name="public-key">{private.publickey}</Property>
</Properties>
<ClassName>com.google.apigee.callouts.GenerateEncryptedJwt</ClassName>
<ResourceURL>java://apigee-callout-encrypted-jwt-20250403.jar</ResourceURL>
</JavaCallout>

Error:

ejwt_exception: java.lang.IllegalStateException: unable to read anything when decoding public key

 ejwt_error : unable to read anything when decoding public key

Solved Solved
1 11 799
2 ACCEPTED SOLUTIONS


@raghunathapalle wrote:

response has three sections separated by period. Is there a way to base 64 decode the response by using the period as delimited ? we see 1. JOSE Header 2. JSON Payload & 3. JWS Signature in the response so how do we handle the base 64 decode, verify signature only for the JWS signature & send the json payload back to the client app?


Well it sounds like the response payload (decrypted) is ... a JWS or JWT.  Probably JWT.

You can use DecodeJWT to split and then base64-decode the header and payload.  (Or DecodeJWS if it is a JWS)  But neither of those policies verifies a signature , which you should do.  

So I would suggest that you try VerifyJWT on the 3-part dot-separated thing.  And somewhere in your environment, you need to have the information about  how to get the public key to verify the signature. I don't know how to solve that, but maybe you do.  

Assuming the public key is available on a JWKS endpoint, the configuration will look like

<VerifyJWT name='VJWT-1'>
  <Algorithm>RS256</Algorithm> <!-- or whatever is appropriate -->
  <Source>jwe_output</Source>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <PublicKey>
    <JWKS uri="https://the.endpoint.for.your.jwks/keys"/>
  </PublicKey>
  <!--
     other elements here 
  -->
</VerifyJWT>

Good, I'm glad you're making progress!

View solution in original post


@raghunathapalle wrote:

We are using VerifyJWS to verify the signature using public key from partner after DecodeJWT. Hope the data is trust worthy after the verifyJWS.


YES.  Either VerifyJWS or VerifyJWT will verify the signature, and after that policy succeeds, your API proxy can be assured that the claims are trustworthy.


@raghunathapalle wrote:

We are seeing that apigeex response flow is skipping the decrypt , Decode & verify for error response from partner(backend). Is there a way to consider 400 & 500 as valid backend errors & do the decrypt , Decode & verify ?


yes, surely. 

You can either

  • Allow Apigee to treat 400 or 500 as an error. This results in a Fault.  Then so the decrypt/decode/verify in a Fault Rule in the target endpoint. 
  • use success.codes on the property in the TargetEndpoint, to indicate 400 and 500 should not cause a fault. See here.

Your choice.

ps: you do not need to decode AND VerifyJWS.  In general, you should perform the DecodeJWS before VerifyJWS only if the DecodeJWS will give you some data from the header, than you need to perform the VerifyJWS. 

View solution in original post

11 REPLIES 11