VerifyJWT - fails with NullPointerException

[tcavaleiro]

Hi community,

we have built a JWT validation flow that does all the standard steps to validate a RS256 token.

LookupCache - retrieve JWKS from cache
ServiceCallout - conditional,  get from jwk_uri if no match on cache
PopulateCache - conditional, update cache 
AssignMessage - conditional, if not from cache copy to variable
VerifyJWT - fails with NullPointerException

Because we thought the issue was related with our internal flow we have made a change to use directly VerifyJWT with an URI but still fails.

When tracing, we can see the keys have been download but the policy is failing with NullPointerException.

Below logs from Message Processor

2024-11-xx aa:bb:cc,005 org:ABC env:abc-DEV api:dummyTest2 rev:10 messageid:<removed>-4286-44484-18 policy:VJ-CheckAuthToken NIOThread@3 ERROR STEPDEFINITIONS.JWT - VerifyJWTStepExecution.verifyJwt() : Exception while verifying JWT {}
java.lang.NullPointerException: null
at com.apigee.steps.jwt.verify.jwt.VerifyJWTStepExecution.verifyJwt(VerifyJWTStepExecution.java:357)
at com.apigee.steps.jwt.verify.jwt.VerifyJWTStepExecution.execute(VerifyJWTStepExecution.java:135)
(...)

Other points noticed:

- if we supply an expired JWT it will throw the expected steps.jwt.TokenExpired error

- when supplying a  valid JWT the NPE will be raised

- the JSON returned by the jwk_uri is a valid json, although we noticed the "alg" property is not been defined, can this be a mandatory field on the Apigee end? meanwhile the provider added the field but still fails

- we are using Apigee OPDK Version 4.52.00.00

Thank you.

[tcavaleiro]

Cannot paste the log content as this is failing with 403 when submitting to "https://www.googlecloudcommunity.com/gc/forums/editpage.editorform.form.form.form".

Been trying to post this on the last hours until finally discovered was the stack trace ☹️

[gonzalezruben]

Could you share your VerifyJWT policy configuration? Make sure to anonymize sensitive fields like keys, passwords, etc.

[dchiesa1]

Can you show the  JWKS?  I think your JWKS might be wrong, corrupted, or something. 

For sure, the VerifyJWT policy should not throw a Null Pointer Exception. That's a bug and you should report it through Apigee Support.  But I'm pretty sure VerifyJWT works with valid JWKS.  so you may be able to avoid the NPE with some more benign input. 

Yknow, you can specify the uri in thee VerifyJWT policy, so you don't have to use ServiceCallout and a cache and all that other stuff.

https://docs.apigee.com/api-platform/reference/policies/verify-jwt-policy#publickeyjwks

your configuration would look like this:

<VerifyJWT name="JWT-Verify-RS256">
    <Algorithm>RS256</Algorithm>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <PublicKey>
      <JWKS uri="https://my-uri.to/a/jwks.json"/>
    </PublicKey>
     ...

I'm not sure if you tried that.  You didn't show any policy configuration. 

Of course, if the JWKS URI varies, you would need to do the ServiceCallout thing. (In Apigee X, you can specify a variable for the uri).  

[tcavaleiro]

@gonzalezruben , this is how our VerifyJWT policy looks.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VerifyJWT async="false" continueOnError="false" enabled="true" name="VJ-CheckAuthToken">
    <DisplayName>VJ-CheckAuthToken</DisplayName>
    <Algorithm>RS256</Algorithm>
    <Source>decryptedAuthToken</Source>
    <PublicKey>
        <!--
        <JWKS ref="public.jwks"/>
        -->
        <JWKS uri="https://somedomain.tld/endpoint/jwk_uri"/>
    </PublicKey>
    <IgnoreCriticalHeaders>false</IgnoreCriticalHeaders>
    <IgnoreIssuedAt>false</IgnoreIssuedAt>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <AdditionalClaims ref="json_claims"/>
</VerifyJWT>

@dchiesa1 found a nice tool which indicates our JWT is valid, key is found and signature verified. So don't think the JWKS endpoints is the culprit.

https://jwt.davetonge.co.uk/

I start to suspect this is related to json_claims on AdditionalClaims. We are currently troubleshooting bit more to reach a conclusion, but we might have found something related to this.

Regarding reporting it via Apigee Support we are trying it but the support portal (although it allows to log in) is not allowing to create a ticket, just keeps on the same page, not sure if it's a general issue or related to our account. 

[dchiesa1 · Accepted solution]

---

@tcavaleiro wrote:

I start to suspect this is related to json_claims on AdditionalClaims. We are currently troubleshooting bit more to reach a conclusion, but we might have found something related to this.

---

yes, you are correct.  I'm sorry , last night when I looked at this, I had missed it.  But it is not related to the JWKS.  It's related to the additional claims. If you remove that, it will probably work.  

---

@tcavaleiro wrote:

the support portal (although it allows to log in) is not allowing to create a ticket,

---

You need to be using https://console.cloud.google.com/support to report support tickets now .  Even if you are using OPDK, you must use console.cloud.google.com for the support portal. That means you need a GCP organization and project set up, and a billing account. 

If you do not have all of this set up, please send an email to saas-support-onboarding@google.com  and ask for assistance. 

[tcavaleiro]

In a nutshell what happened is that on certain conditions the AdditionalClaims JSON was set to empty string instead of empty JSON string 😀. But it shouldn't be throwing an NPE anyway on my view.

Regards to our support account is been resolved today hopefully. I will then refer to this community thread and will recommend an additional improvement.

Our workaround is basically additional a "safe check" Javascript policy before calling

VerifyJWT policy.

var json_additional_claims = context.getVariable("json_claims");

if (json_additional_claims === null || json_additional_claims.trim() === "") {
    context.setVariable("json_claims", "{    }");
}

 Thank you.

[dchiesa1]

---

@tcavaleiro wrote:

But it shouldn't be throwing an NPE anyway on my view.

---

I agree with that completely.  I suggest you ask the support team to file a bug on your behalf.