verify additional claims

[mbrevda]

Would it be possible to extend jwtVerify to accept more claims other than those provided in JWTVerifyOptions? For example:

await  jwtVerify<T>(token, key, {issuer: 'foo', 'myCustomClaim': 'bar'})

[panva]

You can easily do that in your own code following the token's general verification. You can even have it throw the same type of error.

import { jwtVerify } from 'jose'
import { JWTClaimValidationFailed } from 'jose/errors'

let token!: string
let key!: CryptoKey

const verified = await jwtVerify(token, key, { issuer: 'foo', requiredClaims: ['myCustomClaim'] });

if (verified.payload.myCustomClaim !== 'bar') {
  throw new JWTClaimValidationFailed(
	'myCustomClaim validation failed',
	verified.payload, 
	'myCustomClaim', 
	'invalid',
  )
}

[mbrevda]

It would be cleaner and simpler if it could be done in jwtVerify. Instead of only verifying that requiredClaims exist, allow for passing an object so that their values can be verified, too.

(feel free to close this if you disagree)

[panva]

It would undeniably result in less code the user has to write but jury's out on whether that's any "cleaner".

It would arguably not be enough to just allow checking for strict value comparison. The module would have to have a syntax to only check the claims value optionally, or to be matching a regexp, to be within a certain range (i.e. number claims), as you can see the complexity starts to raise and soon enough you're at a level where schemas such as https://github.com/colinhacks/zod are needed.

Given that you can just as easily describe and check your own business logic after the token's integrity and its standard-defined validity claims are verified I do argue whether bloating jwtVerify it is the right place to be doing so.

[mbrevda]

prehaps strict matching + a function predicate for more flexibility could work as a compromise?

type CustomClaims = Record<string, string | number> | (() => boolean);

[panva]

So in the function predicate you'd essentially write the very same code you can do after the token's integrity and its standard-defined validity claims are verified. I don't see the point.