Behavior differences between local environments and Lambda

[sudduth]

I'm doing JWT validation for a token generated by AWS Congnito with ...

jose.JWT.verify(token, pem);

This works great from a test harness. It works great running in a lambci/lambda:nodejs10.x Docker image. However, when I deploy the code to Lambda the signature validation fails. In all cases the inputs (token, pem) are exactly the same.

After a little digging it seems the key object that's passed into the second arg of the rsassa.js:verify method ....

const verify = (nodeAlg, { [KEYOBJECT]: keyObject }, payload, signature) => {...}

... looks something like this ...

   {kid: "alphanums", e: "AQAB", n:"alphanums", kty: "RSA"}

... in the calling method and comes into verify() as a KeyObject object. (Honestly, it's unclear to me what bit of JS finesse makes that transformation happen ...) However, on Lambda it isn't happening. The value in verify() stringifies as ...

  {}

So, my question is: Any idea what's going wrong there?

[panva]

I wouldn’t worry about how it stringifies. IIRC cloudwatch has something fishy going on when it comes to object inspection.

Also it might be you’re running different node version, on 10 there’s a custom keyobject like object, on 12 onward its an actual crypto.KeyObject instance.

Why don’t you post the public key and the jwt in here so i can try when i have the time.

My guess is, the inputs aren’t actually the same but i’ll give you the benefit of the doubt.

[sudduth]

Here's the token and key I've been using ...

eyJraWQiOiJydDBSSkVldm1xZmlqeUxudEVCY3BzSzVySUEwZHdvT2hqRE9DRDI3Q2EwPSIsImFsZyI6IlJTMjU2In0.eyJzdWIiOiI1b2w5bWlyZjBwbXJvajJkamsyZ3JqZjFhZiIsInRva2VuX3VzZSI6ImFjY2VzcyIsInNjb3BlIjoiZm9vX3Jlc291cmNlXC9hbGwiLCJhdXRoX3RpbWUiOjE1ODEzNjkxNTAsImlzcyI6Imh0dHBzOlwvXC9jb2duaXRvLWlkcC51cy13ZXN0LTIuYW1hem9uYXdzLmNvbVwvdXMtd2VzdC0yX3RyaElDQTdnbiIsImV4cCI6MTU4MTM3Mjc1MCwiaWF0IjoxNTgxMzY5MTUwLCJ2ZXJzaW9uIjoyLCJqdGkiOiJmMjRiNDFmYy0zZDM3LTQ5NTktODg4NC1lOTgyN2UzNmNkMjgiLCJjbGllbnRfaWQiOiI1b2w5bWlyZjBwbXJvajJkamsyZ3JqZjFhZiJ9.M14H6J3kib2UWQbk_RSPPf4dF__ilzO-gq0uV4Tfs1Woo-EJ9yFiiLG8EAhPtMoY9aBbIi7dm2yvds8Hej_ohio0mxPjgnJ2OZwT5N7J8MO9hNLsSj92gqZO_jIBUlK088KAP6oSLBniDosfDyMkk0HzvclgYcp7dYv8VQNWPxVRZbEHdHEM7_qNz2FF1joO5S4L9lITxDbwOXmB5wCXiE3z3VXJU4WfsRqZLf1Vl29X6qkWu6ANx9HTrc7qowq-yoRPG_QqLcBqBaDyErcfdXN1eV8KnS6VBnis4tFcHtWXbjh2i5pHNjxDCnEVkWfWCMcbb2M2QYbvGlgRF01RGA
   
 -----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEAgA97jWcK13cGlDPkB/K/Tk9T+or8temKZSQa8jlJI2h+GV15k7z4
pFM5TOhg6Hw+JiUuhFl2PYznBk7U+rbUgDxo6TZ0dWtpJeiivGxhRCom4PCb6SR+
9lCP1aMl8v2EqKzPs2E8acEr+Pwv2WSxg2KvsDMjNo1PK72c/2Q61i5flLEHTioV
Dx9HibD+SFAyem1qXU0arYGqHnHhEnybpH/j8zm30nMeHTwgUHaeQnFe/iDd3RU6
ft+KdgRyG8vr6tmglDRH1yKMO8t9n9N4RQaBu33s+OS6aby4iTljEBijum9jYxLp
8qppXvlhVYm+QCDCxtZjVGoBSnHC4ALRxQIDAQAB
-----END RSA PUBLIC KEY-----

Some additional notes:

I called stringify like console.log(JSON.stringify(keyObject)), so I don't think Cloudwatch wonkiness was in the mix.

I was thinking that there might be a difference in the Node crypo module between 10x and 12x, so I tried both and didn't see any difference in the outcome.

I was able to get the validation to succeed by hardcoding the pem like ...

const verify = (nodeAlg, { [KEYOBJECT]: keyObject }, payload, signature) => {
   // let secret =  asInput(keyObject, true)
   let secret = ` -----BEGIN RSA PUBLIC KEY----
my pem etc etc`;
    return createVerify(nodeAlg).update(payload).verify(secret, signature);
}

Thank you very much for your time.

[panva]

Don't get bogged down on the keyObject content you logged. I'll get my own lambda deployed when I have the time to see if there is an issue or not. I still don't believe there is.

[panva]

@sudduth

const jose = require('jose')

const jws = `eyJraWQiOiJydDBSSkVldm1xZmlqeUxudEVCY3BzSzVySUEwZHdvT2hqRE9DRDI3Q2EwPSIsImFsZyI6IlJTMjU2In0.eyJzdWIiOiI1b2w5bWlyZjBwbXJvajJkamsyZ3JqZjFhZiIsInRva2VuX3VzZSI6ImFjY2VzcyIsInNjb3BlIjoiZm9vX3Jlc291cmNlXC9hbGwiLCJhdXRoX3RpbWUiOjE1ODEzNjkxNTAsImlzcyI6Imh0dHBzOlwvXC9jb2duaXRvLWlkcC51cy13ZXN0LTIuYW1hem9uYXdzLmNvbVwvdXMtd2VzdC0yX3RyaElDQTdnbiIsImV4cCI6MTU4MTM3Mjc1MCwiaWF0IjoxNTgxMzY5MTUwLCJ2ZXJzaW9uIjoyLCJqdGkiOiJmMjRiNDFmYy0zZDM3LTQ5NTktODg4NC1lOTgyN2UzNmNkMjgiLCJjbGllbnRfaWQiOiI1b2w5bWlyZjBwbXJvajJkamsyZ3JqZjFhZiJ9.M14H6J3kib2UWQbk_RSPPf4dF__ilzO-gq0uV4Tfs1Woo-EJ9yFiiLG8EAhPtMoY9aBbIi7dm2yvds8Hej_ohio0mxPjgnJ2OZwT5N7J8MO9hNLsSj92gqZO_jIBUlK088KAP6oSLBniDosfDyMkk0HzvclgYcp7dYv8VQNWPxVRZbEHdHEM7_qNz2FF1joO5S4L9lITxDbwOXmB5wCXiE3z3VXJU4WfsRqZLf1Vl29X6qkWu6ANx9HTrc7qowq-yoRPG_QqLcBqBaDyErcfdXN1eV8KnS6VBnis4tFcHtWXbjh2i5pHNjxDCnEVkWfWCMcbb2M2QYbvGlgRF01RGA`

const pem = `-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEAgA97jWcK13cGlDPkB/K/Tk9T+or8temKZSQa8jlJI2h+GV15k7z4
pFM5TOhg6Hw+JiUuhFl2PYznBk7U+rbUgDxo6TZ0dWtpJeiivGxhRCom4PCb6SR+
9lCP1aMl8v2EqKzPs2E8acEr+Pwv2WSxg2KvsDMjNo1PK72c/2Q61i5flLEHTioV
Dx9HibD+SFAyem1qXU0arYGqHnHhEnybpH/j8zm30nMeHTwgUHaeQnFe/iDd3RU6
ft+KdgRyG8vr6tmglDRH1yKMO8t9n9N4RQaBu33s+OS6aby4iTljEBijum9jYxLp
8qppXvlhVYm+QCDCxtZjVGoBSnHC4ALRxQIDAQAB
-----END RSA PUBLIC KEY-----`

module.exports.handler = async () => {
  console.log('process.versions', process.versions)
  const jwk = jose.JWK.asKey(pem)
  console.log('jwk', jwk)

  console.log('jose.JWT.verify(jws, jwk)', jose.JWT.verify(jws, jwk, { ignoreExp: true }))
  console.log('jose.JWT.verify(jws, pem)', jose.JWT.verify(jws, pem, { ignoreExp: true }))
}

I added ignoreExp: true just so that i can pass the claim validation, normally you wouldn't do that, its just that the JWT you provided is by now expired.

The above works fine in both nodejs10.x and nodejs12.x Lambda runtimes with the latest jose package from npm (v1.22.2).

The only wrong thing in what you've pasted is the extra space character at the start of your PEM key. That needs to be removed otherwise the key won't import to a key object.

I'm sorry to say so but, from my end, there's nothing weird happening in lambda. There's no room for lambda execution to behave any differently. If things work for you locally and not in lambda, maybe the way you get the JWT / PEM values out of the event context or environment variables is wrong.

As a sidenote, use node 12, and work with a jose.JWK.Key (instantiated by jose.JWK.asKey as seen in my code) or jose.JWK.KeyStore when working with multiple keys, it's a massive performance boost as it uses the native crypto (node >= 12) KeyObject API.