Verification fails with custom header parameter sigT in JWT

[rober12]

I'm encountering an issue when trying to verify a JWT using the jose library that contains custom header parameters, specifically sigT included in the JWT header and declared inside the crit array.

Example header snippet:

{
  "alg": "RS256",
  "sigT": "2025-06-18T13:51:51Z",
  "crit": ["sigT"],
  "x5c": [ "...certificate data..." ]
}

When calling jwtVerify() or flattenedVerify() with the corresponding public key, the verification fails with the error:

Extension Header Parameter "sigT" is not recognized

I have tried to use the critHandlers option to handle this custom header, but the error persists.

Expected behavior:

The library should allow custom critical headers like sigT to be recognized and accepted when declared in the crit array, and the verification should succeed if the signature and key are valid.

Environment:

• jose version: 6.0.11 (and also tested with 5.2.0)
• Node.js version: v18.19.0
• Code snippet used for verification:

const { payload, protectedHeader } = await jwtVerify(token, publicKey, {
  critHandlers: {
    sigT: (value) => {
      // custom validation for sigT
    }
  }
});

Any advice or fixes would be greatly appreciated.

Thank you!

[panva]

Hi @rober12

I have tried to use the critHandlers option to handle this custom header, but the error persists.

There isn't (and never was in the past) such named option in this or previous jose versions.

The library should allow custom critical headers like sigT to be recognized and accepted when declared in the crit array, and the verification should succeed if the signature and key are valid.

You can acknowledge "recognized" crit extensions using the crit verify option. This takes an object where its property names are the recognized crit header parameter names and its values are booleans - true when the Header Parameter MUST be integrity protected, false when it's irrelevant.

Since these custom crit headers do not change how the signature verification is performed or how the JWT payload is encoded (like e.g. the b64 extension does) you are expected to finish processing such headers after the invocation of jwtVerify/compactVerify succeeds in your own codepath.

[rober12]

Thanks a lot for the clarification!
It was indeed a misunderstanding on my part — I was using critHandlers instead of the proper crit verification option.

crit: { sigT: true }

resolved the issue perfectly.

Appreciate your quick and helpful response.