How to verify decoded token

[jonaskello]

I want to decode the token first to get an unverified claim out, then verify the token. Since I already decoded the token I want to avoid the cost of decoding it one more time during verification and just verify the already decoded token. Is there some way to do this?

The reason for decoding first is that we use a tenant claim to fill in the url template for the jwksuri.

I think of it something like this in code (does not work):

    const decodedToken = Jose.decodeJwt(encodedToken);
    // Codes that builds jwksUri as a function of decoded token
    const jwksUri = buildUrl(decodedToken);
    const jwks = Jose.createRemoteJWKSet(new URL(jwksUri));
    const { payload, protectedHeader } = await Jose.jwtVerify(decodedToken , jwks);

[panva]

There's compactVerify, but I recommend against it in your case since you're losing on validating the JWT Claims Set that, as documented, is not part of decodeJwt. You'd only be saving yourself one JSON.parse anyway so this is not worth it.

[jonaskello]

Thanks for the quick reply :-) So you would recommend something like this?

    const decodedToken = Jose.decodeJwt(encodedToken);
    const jwksUri = buildUrl(decodedToken);
    const jwks = Jose.createRemoteJWKSet(new URL(jwksUri));
    const { payload, protectedHeader } = await Jose.jwtVerify(encodedToken, jwks);

The reason I'm looking to minimize parsing is that this code is called on every request. My thinking is that skipping the extra parsing, even if it has minimal impact when run once, may have some significance if there are many requests.

Does the "validating the JWT Claims Set" mean checking the well-known claims like "iss", "sub" etc? Is there some other way to run that validation as a separate step?

[jonaskello]

Btw I also read this in #598

types: jwtVerify and jwtDecrypt type argument for the resolved KeyLike type is now a second optional type argument following a type for the JWT Claims Set (aka payload)

That sounded to me like it was possible to pass JWT Claims Set as input to jwtVerify but perhaps I'm reading it wrong.

[panva]

The reason I'm looking to minimize parsing is that this code is called on every request. My thinking is that skipping the extra parsing, even if it has minimal impact when run once, may have some significance if there are many requests.

You're focusing entirely on the wrong optimization. What you want to focus on instead is ensuring that you're using a trusted jwksUri and then caching the result of createRemoteJWKSet, using the jwksUri as the cache key.

Trusting any jwksUri is clearly a problem, you need to have an allow list or somehow ensure you want to accept a specific URL.

even if it has minimal impact when run once

It has a minimal impact even when run tons of times.

So you would recommend something like this?

No, not really. For the reasons above.

import * as jose from "jose";
import { LRUCache } from "lru-cache";

const cache = new LRUCache({ max: 100 });
const { payload, protectedHeader } = await jose.jwtVerify(
  jwt,
  async (header, jws) => {
    const unverifiedPayload = JSON.parse(
      new TextDecoder().decode(jose.base64url.decode(jws.payload))
    );
    const jwksUri = buildUrl(unverifiedPayload);

    if (!isTrusted(jwksUri)) {
      throw new Error();
    }
    let JWKS;
    if (!cache.has(jwksUri)) {
      cache.set(jwksUri, jose.createRemoteJWKSet(jwksUri));
    }
    JWKS = cache.get(jwksUri);
    return JWKS(header, jws);
  },
  {
    issuer: "urn:example.com",
    audience: "urn:example.com",
    // ... other verification options
  }
);

Does the "validating the JWT Claims Set" mean checking the well-known claims like "iss", "sub" etc?

And exp, nbf, etc, yes.

Is there some other way to run that validation as a separate step?

No.

That sounded to me like it was possible to pass JWT Claims Set as input to jwtVerify but perhaps I'm reading it wrong.

You are reading it wrong. That's merely a type-thing, if you know the types for application-specific claims using that generic is one way of being able to tell typescript there's a property and what is its type. I prefer narrowing instead but some users were adamant on being sure what their payloads are like and trust them after signature verification.

[jonaskello]

Thanks for the detailed answer and example, that was very useful :-)