The change is good to me, however, what is the use case for this change?
I saw the comment in the code, but if the token was already verified according to the options passed, what is the need for header + signature apart from the payload?

Thanks @ziluvatar for the response.

My motivation to include this feature was that inside verify method there is already a call to decode passing { complete: true } option:

My use case requires to verify the token and also returns the full JWT (header, payload, signature) after verifying it. For now, I do 2 calls: one to verify and another one to decode if the verification goes OK. If we have this option in verify method I can avoid the second call to decode method because it's already done inside verify.

My use case requires to verify the token and also returns the full JWT (header, payload, signature) after verifying it.

That's how you want to get it done, I'm asking what the use case is for the need of returning the full JWT, what do you need to do with the header or the signature? I want to understand the root reason better.

@ziluvatar there may be any number of additional properties in the JWS protected header a developer may want to access. Exposing this option would save extra processing of something which was already parsed once.

I can see:

//return header if complete option is enabled. header includes claims
//such as kid and alg used to select the key within a JWKS needed to
//verify the signature

@javespi Currently that use case can be achieve by passing the getSecret(header, cb) function as "secret".

Anyway, if you remove that comment I'll merge the PR.

Thanks @ziluvatar and @panva for your feedback. I've already removed that comment.

Thanks @javespi ! 🎉 Released on v8.5.0

@ziluvatar thanks to you! Great project!