Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding option to not validate jwt #130

Closed
kdstew opened this issue Dec 16, 2015 · 14 comments
Closed

Adding option to not validate jwt #130

kdstew opened this issue Dec 16, 2015 · 14 comments

Comments

@kdstew
Copy link

kdstew commented Dec 16, 2015

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
Copy link
Member

@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
Copy link
Author

kdstew commented Dec 16, 2015

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
Copy link
Member

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

@kdstew
Copy link
Author

kdstew commented Dec 16, 2015

Yes, that is the goal.

@sathishsoundharajan
Copy link

@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
Copy link

@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
Copy link
Member

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

@vdeturckheim
Copy link

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

@nelsonic
Copy link
Member

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

@nelsonic
Copy link
Member

@kdstew I have implemented a way to bypass_verifcation see:

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
Copy link
Author

kdstew commented Dec 18, 2015

@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
Copy link
Member

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

@nelsonic
Copy link
Member

Added the option to customVerify (pretty much what you have requested)
but now need to add some documentation to the Readme before releasing.

@nelsonic nelsonic mentioned this issue Dec 21, 2015
@nelsonic
Copy link
Member

@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...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants