Adding option to not validate jwt

[kdstew]

The use case here is our hapi server is siting behind a gateway that is validating the jwt token as the requests come through. So by the time the request makes it to the hapi server we already know the token is valid. But we do want to access the jwt payload to use the information. Would you be open to the addition of this functionality? I'd be happy to work up a PR if you are.

[nelsonic]

@kdstew, is the auth header preserved?
If you already know the request is valid, you can simply define your validate function to return true every time.
We can write you a quick example if unclear.

[kdstew]

Yes the auth header is passed through the gateway.
I gave that a try, but without the key being specified in the options key as a value or in a key function the request fails with an Invalid token response. One of our goals is to not have to distribute the jwt secret key to the servers running behind the gateway.

[nelsonic]

Is your gateway the only element that knows the JWT key/secret?

[kdstew]

Yes, that is the goal.

[sathishsoundharajan]

@kdstew If that is your goal, without knowing the secret key jwt cannot decode the token and pass the payload back to you.

Option to stop the validate is not the right way.

If you can maintain the key/secret in the Hapi itself, then you can write your own validate function as @nelsonic told above.

Another way would be, in the gateway(Layer7/CA/ApiGee)? you can send the decoded values in the
request payload / request header.

Hope this helps.

[vdeturckheim]

@bboysathish

@kdstew If that is your goal, without knowing the secret key jwt cannot decode the token and pass the payload back to you.

What about the use of asymmetric cryptography while signing jwt ?

[nelsonic]

@kdstew, promise I'm not ignoring your request, just considering its implications for how the module is currently written ...

[vdeturckheim]

Maybe the solution lays in the use of RSA based encryption in this situation.

[nelsonic]

@vdeturckheim yes, encryption could be a good solution here.
However, I think @kdstew wants to keep the request lifecycle light-weight ...

[nelsonic]

@kdstew I have implemented a way to bypass_verifcation see:

hapi-auth-jwt2/lib/index.js

Lines 49 to 51 in d44bf4b

	if(options.bypass_verifcation) { // see: https://github.com/dwyl/hapi-auth-jwt2/issues/130
	return reply.continue({ credentials: decoded, artifacts: token });
	} // make token available in request.auth.credentials but skip JWT.verify

Please check it and confirm.

However since there is overlap between this and #120 (custom verification)
we are hoping to release both features in one go.

[kdstew]

@nelsonic Thanks for working through this. The bypass_verification option looks like it would accomplish the goal of getting the payload into the auth.credentials without verification.
It would also be nice to have a bypass function that would get called on bypass, so that some checks could be made against the payload or manipulation of the payload could be made. Something like the following based on your earlier additions.

if(options.bypass_verifcation) { // see: https://github.com/dwyl/hapi-auth-jwt2/issues/130
  if (typeOf option.bypassFunc === 'function') {
    options.bypassFunc(decoded, request, function(err, valid, credentials) {
      if (err) {
        return reply(Boom.wrap(err));
      }
      else if (!valid) {
        return reply(Boom.unauthorized('Invalid credentials', 'Token'), null, { credentials: credentials || decoded });
      } else {
        return reply.continue({ credentials: credentials, artifacts: request.auth.token });
      }
    });
  } else {
    return reply.continue({ credentials: decoded, artifacts: request.auth.token });
  }
} // make token available in request.auth.credentials but skip JWT.verify

[nelsonic]

@kdstew, that's what @stongo requested in #120
So I'm going to spend a bit of time writing it now.