Adding option to not validate jwt
kdstew opened this issue · comments
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.
@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.
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.
Is your gateway the only element that knows the JWT key/secret?
Yes, that is the goal.
@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.
@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 ?
@kdstew, promise I'm not ignoring your request, just considering its implications for how the module is currently written ...
Maybe the solution lays in the use of RSA based encryption in this situation.
@vdeturckheim yes, encryption could be a good solution here.
However, I think @kdstew wants to keep the request lifecycle light-weight ...
@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
Added the option to customVerify (pretty much what you have requested)
but now need to add some documentation to the Readme before releasing.
@kdstew the latest release 5.3.0 has added support for custom verification by supplying a verifyFunc which gives you complete control over the verify process.
It also means you can bypass verification completely if you wish.
to bypass JWT verification simply callback with null, true, decoded e.g:
var customVerifyFunc = function (decoded, request, callback) {
return callback(null, true, decoded);
};Let us know if you need anything else. 👍
(Closing this issue as I think its resolved, but feel free to re-open if not...)