Any way to get the raw token?

[poxrud]

hi, I need to get the raw token for blacklist/whitelist purposes. The verify(jwtPayload, done) callback only provides me with the already decoded jwt, I would have to encode it again (wasteful) to get back the original jwt.

I know that I can set passReqToCallback : true to get access to the req object. But then I need to run the extractors on req again, which is wasteful since they've already been run once. Any ideas?

thanks.

[poxrud]

If I get the go ahead I can push a PR to support this.

• I can add the token to the jwtPayload object (easiest) OR
• I can introduce another option to JwtStrategy such as passRawTokenToCallback then pass it as an argument to the verify function. OR
• Attach it to the req object that we get with passReqToCallback : true

[mikenicholson]

I know that I can set passReqToCallback : true to get access to the req object. But then I need to run the extractors on req again, which is wasteful since they've already been run once. Any ideas?

This is the recommended way to do what you want. Rather than making a bunch of one-off options for every possible bit of extra info a user might need in the verify call back we provide the whole request and let the user fetch whatever they want from it.

I don't think the extract functions are particularly expensive to run so it doesn't seem like this use case justifies extra options.

Modifying the jwtPayload is not a good idea since we could overwrite existing keys and the only way around this would be to provide an additional configuration option for the strategy.

[mikenicholson]

Didn't mean to close yet, just comment.

[poxrud]

Thanks for the reply.

The change that I was suggesting is one line in lib/strategy.js.

payload = {...payload, rawJwt: token};

But now I see that this will create a potential issue if someone creates a private claim called 'rawJwt'.

I don't think the extract functions are particularly expensive to run so it doesn't seem like this use case justifies extra options.

Without the changes this is the method I will have to follow. Just does not feel very elegant to run the same extractors twice, especially since I'm dealing with multiple extractors (Auth header, cookie, body params).