Can not verify JWT signed by Auth0 (`api.redirect.encodeToken`)

I am implementing progressive profiling following the auth0 documentation and I am stuck verifying a JWT signed by Auth0 following documentation on Pass[ing] data to the external Site. I am able to verify the token generated by api.redirect.encodeToken using jwt.io, but fail to do the same validation with the jsonwebtoken (v9) library. A similar issue has been reported in 2018 [1].

The code I am using inside of the onExecutePostLogin function is:

    const sessionToken = api.redirect.encodeToken({
      payload: {
        user_id: event.user.user_id,
      },
      secret: "my-action-specific-secret",
    });

In the client facing application for progressive profiling, I do now want to verify this token basically using:

const jwt = require("jsonwebtoken");
jwt.verify(token, "my-action-specific-secret", { algorithms: ['HS256'] });

The code presented is simplified but represents what I am doing. My issue can easily be reproduced here: RunKit where one can see the token verification failing with an invalid signature error. The same token however can be verified successfully on jwt.io: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwczovL3RvcGl4LmF1dGgwLmNvbS8iLCJzdWIiOiJhdXRoMHw1YmJjZmVhYjY4YTU2YzRjNTEzMjIyM2MiLCJhdWQiOlsiaHR0cHM6Ly90b3BpeC5pby90ZXN0Il0sImlhdCI6MTUzOTQ3NTQ5NSwiZXhwIjoxNTM5NDgyNjk1LCJhenAiOiJTaWNWUUlQRFJqQ2t2WVFFaTQ2bFNJWFhUeVllc1RJWCIsInNjb3BlIjoib3BlbmlkIHByb2ZpbGUifQ.gpITTza7SLoELnC9iTbzTjZ9aZCS8oWhsh5NEaDjmQI with the secret cE9d0Vy07dFxD3SOnpiAYLwwkDno7ZB6.

I am out of ideas debugging this issue and would appreciate help. Thanks!

[1] Why does jwt.verify() give "invalid signature"?

Hey there @t.koenig welcome to the community!

Thanks for the detailed description of the issue, very helpful :slight_smile:

Where are you getting the secret you’ve shared from? It looks to be an API signing secret.

In looking at the code post-login action code here, you will need to verify the token using the secret defined at secret: event.secrets.MY_REDIRECT_SECRET as opposed to the API secret. I’m not positive this is the issue you’re running into, but it seems like an easy mistake to make.

Keep us posted!

Hi @tyf, thank you for looking into my issue! The secret being used for signing and for verification is the same. Is it relevant “where it comes from”?

As you can see in the example provided, the token verifies just fine on jwt.io but -using the exact same secret- does not verify using the library.

Hey no problem, happy to help where I can!

It doesn’t, I just wanted to make sure there wasn’t a mismatch anywhere as that’s a common mistake.

Are you able to reproduce this with a token generated using your own environment and relevant Action secret? I am up to this point unable to - The session_token I get back as a param in the redirect url can be both verified at jwt.io as well as within the RunKit example shared :thinking:

1 Like

Thank you for trying to reproduce my issue. I’ve done the same again from a blank slate and can confirm that it works now. I assume I’ve messed with the secret while pasting it into the Auth0 Action Secrets UI…
2023-05-26_21-17

What ultimately led to me thinking that I didn’t make a mistake with the secret was that jwt.io verified the token’s signature just fine - accepting an incorrect secret! While my original issue is solved, it might make sense to expand on this observation. Revisiting the original token from 2018 on jwt.io (token in the link), I observe that jwt.io says “Signature Verified” even if I provide an incorrect secret as illustrated below. Is this the intended behavior?

Hey @t.koenig no problem, happy to help and good to know you were able to get it sorted :slight_smile:

Hmm good point! On second look I believe that the “Verify Signature” bit isn’t designed to be used to take an existing secret and verify the token, but rather to add a signature to the token. If you add in any text there you’ll see it appends to the end of the token. I just tried entering a random secret for the token you shared (updated the expiration time to be valid) and then verified it in Runkit with the secret I used to sign it in jwt.io. A bit confusing I agree :thinking:

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.