How to get decoded value of JWT in response?

[abhinabanag92]

I am calling an API proxy to decode JWT (passing it as Authorization Header),

I have added Policy JWT Decoder, in the ProxyEndpoint preflow response.

I am able to see the decoded values of the JWT in the EDGE Trace console.

I want the values in the JSON response of the API proxy as well.

[abhinabanag92]

I am using Assign Message Policy as well in the in the ProxyEndpoint preflow response .

[sujnana]

I think the payload is available in flow variable called payload-json (jwt.<policyname>.payload-json).

[abhinabanag92]

Yes, @Sujnana it was available. I was trying write it out in the API response. It is working fine now.

[sidd-harth · Accepted solution]

..

You need to form your payload using the flow variables shown in the Trace session.

In the response side add an Assign Message policy and use Set >> Payload and add all the required flow variables.

jwt.{policy_name}.{variable_name}

<AssignMessage name="set-payload-1">
  <Set>
    <Payload contentType="application/json">
"audience":"jwt.JWT-Decode-1.claim.audience"
</Payload>
  </Set>
</AssignMessage>

[dchiesa1]

I understand you are using the DecodeJWT policy, and you want to examine the decoded claims.

I highly suggest that you take care when doing this.

DecodeJWT does not verify the JWT. It merely decodes it. That means that it might be a completely contrived JWT with an invalid signature. Do not rely on, or trust, the claims that you receive from a DecodeJWT policy.

There MAY BE a reason to decode a JWT with the DecodeJWT policy - to retrieve items from the header that may help determine which key to use to verify the signature in a subsequent VerifyJWT policy. For example the key id. If this is not what you are doing - if you are not using DecodeJWT and VerifyJWT in concert, then you are probably doing it wrong, and you probably don't want to use DecodeJWT alone.

---

Having said that, after the DecodeJWT policy, you can find the claims in this context variable:

jwt.POLICYNAME.decoded.claim.CLAIMNAME

If the claim is "foo" and the DecodeJWT policy is named DecodeJWT-1, then the variable name is:

jwt.DecodeJWT-1.decoded.claim.foo

If you would like to see the entire JSON payload then you can reference this variable:

jwt.DecodeJWT-1.payload-json

You will need to JSON.parse() that or run it through jsonPath to retrieve an individual claim.

The VerifyJWT policy sets variables in the same way.

---

Previous versions of the DecodeJWT policy set variables like this:

jwt.JWT-Decode-1.claim.audience

Note: there is no ".decoded" segment in that variable name.

In this case, the "audience" is a full english word despite the fact that the actual claim name is "aud". This was originally intended as a "convenience" for the registered claims. "sub" transformed to "subject", "iss" transformed to "issuer", "exp" transformed to "expiry", and so on. However, this intention doesn't work very well with some registered claim names like "x5t" and "x5c", which correspond to "x.509 Certificate Thumbprint" and "x.509 Certificate Chain". Those long names are a bit wordy. As a result, the execution on the "long names" was half done. Kind of unsatisfying. To retrieve the subject you needed to use ".subject" while to obtain the x5t you needed to use ".x5t". IT required too much special knowledge. It wasn't simple to explain (some claims get longer names and some don't). That's always a bad sign.

A further complication is that the audience claim is an array, and it was serialized in a non-JSON form. An audience that included "A" and "B" was serialized as "[A,B]". This is not JSON parseable.

We could not change any of that behavior because there are systems running in production that depend on that behavior. Nevertheless we thought we could improve things for future adopters.

As a result we've decided to employ a new naming convention for the variables set by the DecodeJWT and VerifyJWT policies. The .decoded variable names will always use the short claim names (no elaborations from "sub" to "subject").

The policy will continue to set variables with the "legacy" claim names. But the ".decoded" variable names will be easier to use, easier to find, and always JSON.

[abhinabanag92]

Thank you @Dino-at-Google for your detailed response. This will surely be very much helpful for all, following this. Yes, I am using both Verify JWT Policy and Decode JWT policy, but, in separate API proxy calls.