Decode/Verify JWT policy unable to write to variable

[sumit-datta]

Hi,

I have written a Proxy API (/accesstoken) wherein I am generating a JWT token using APIGEE's Generate JWT Token Policy and then returning the JWT token to client application in Response header.

Now, client application calls /product API and passes the JWT token in Request Header. Inside /product Proxy API, I call a shared flow (named API Authorization). Inside this shared flow, if I use the Decode or Verify JWT policy, APIGEE is unable to store the decode claims in local variable even though I can see that it has successfully decoded. Under Trace, I can see the Claims value prefixed with "/=" indicating that Policy is unable to write the value. See the attached screenshot. Surprisingly, I also do not get any Policy error.

However, if I try to Decode/Verify JWT inside /product Proxy API, everything works well and APIGEE is able to store the claims in local variable.

Can someone tell me what could be the problem with Shared flow? I am planning to include the API Authorization logic inside this shared flow and then include it in all of my other Proxy APIs. Therefore, this JWT decode logic needs to work inside the Shared flow as well.

Thanks,

Sumit

[sidd-harth]

Generally speaking,

• An equals sign (=) indicates the value that was assigned to the variable.
• A crossed-out equals sign (≠) indicates that the variable could not be assigned a value because it is read-only or there was an error in policy execution.

BTW did you check the next JS policy are these variable available there??

[sumit-datta]

@Siddharth Barahalikar Yes, I looked at subsequent policies as well but the trace still shows the data could not be assigned to variable. I am wondering what's the difference between Shared Flow and Flow defined within a Proxy so far as JWT Decode is concerned.

[dchiesa1]

Do you have a variable called "jwt" ? It would prevent setting a variable called "jwt.Verify-JWT-1.claim.id" and so on.

[sumit-datta]

Thanks @Dino-at-Google. I was using a variable called jwt. After renaming it, this issue is resolved.