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

Overriding JWT's expiresIn with a value more than 20d prevents users from signing in #458

Closed
ghost opened this Issue Mar 22, 2017 · 11 comments

Comments

Projects
None yet
4 participants
@ghost
Copy link

ghost commented Mar 22, 2017

UPDATE: I forked this and tried running the tests locally, inspecting the tokens generated, and they seem to have a correct exp value. What gives?

I am trying to make a token expire a little longer than the default '1d', however, when I try a value greater than '20d', users are no longer able to sign in the app. I noticed that on the utils.js test cases, a value of '1y' was used but the token created was never 'asserted' to have a valid exp value.

I am aware that having a long enough token expiry is bad for security reasons, but I am just curious why this is not working properly.

@ghost ghost closed this Mar 22, 2017

@ghost ghost reopened this Mar 22, 2017

@ghost

This comment has been minimized.

Copy link
Author

ghost commented Mar 22, 2017

I re-opened this issue because I really want to know what's going on. This really got me frustrated as I have no idea what I am doing wrong, just by setting the expiresIn field greater than 21d causes all my 'integration tests' which uses feathers-authentication-client to fail with this error message:

NotAuthenticated: No auth token
      at NotAuthenticated.ExtendableBuiltin (node_modules/feathers-errors/lib/index.js:21:28)
      at NotAuthenticated.FeathersError (node_modules/feathers-errors/lib/index.js:96:116)
      at new NotAuthenticated (node_modules/feathers-errors/lib/index.js:149:117)
      at node_modules/feathers-authentication/lib/hooks/authenticate.js:79:31

If I change the expiresIn to 20d or less, it works again, as expected. This project uses Socket.io as the sole provider.

Versions:

  • "feathers-authentication": "1.1.1"
  • "feathers-authentication-client": "0.3.1"
  • "feathers-authentication-jwt": "^0.3.1"
  • "feathers-authentication-local": "^0.3.3"

Thank you in advance.

@ekryski

This comment has been minimized.

Copy link
Member

ekryski commented Mar 23, 2017

Hey @johncrisostomo,

I honestly have no idea. It may be something to do with the underlying node-jsonwebtoken library that is being used. We're not doing anything to limit that and there isn't any issue or mention of a cap on the TTL of a JWT in the jsonwebtoken lib.

As you said, we don't recommend having tokens that long anyway but you might want to ask over on the node-jsonwebtoken module if there is a limitation on the expiresIn field.

@jamesholcomb

This comment has been minimized.

Copy link

jamesholcomb commented Mar 23, 2017

@ekryski Are you recommending refresh token strategy in lieu of a long expiration token?

@marshallswain

This comment has been minimized.

Copy link
Member

marshallswain commented Mar 23, 2017

@jamesholcomb there's no blanket recommendation, really. It depends on each service's security requirements. Generally, using refresh tokens on a service will allow you to take advantage of JWT auth not requiring a round trip to the db. Shorter expirations and using refresh tokens will probably be more secure than long expirations.

@jamesholcomb

This comment has been minimized.

Copy link

jamesholcomb commented Mar 23, 2017

I need to secure every service endpoint with a JWT and short expiration (1d). Do I have to roll my own refresh token solution?

@marshallswain

This comment has been minimized.

Copy link
Member

marshallswain commented Mar 23, 2017

@jamesholcomb You can either roll your own, or if you're on a moderate- to low-traffic app, query the db in a hook and check that the user hasn't been blocked. We will eventually release an official solution.

I'd offer a timeline, but the workload is too intense. ;)

@ghost

This comment has been minimized.

Copy link
Author

ghost commented Mar 23, 2017

@ekryski That's the reason why I also got confused. I checked the tokens generated under "when adding custom options" in utils.test.js and it's giving me a valid token. So I kind of know that the issue isn't on feathers-authentication alone, but with somewhere else. I'll look into it more this weekend as I am really curious as to what is causing it.

@ekryski ekryski self-assigned this Apr 11, 2017

@asdacap

This comment has been minimized.

Copy link
Contributor

asdacap commented Apr 29, 2017

Hi there, I'm having the same issue. It seems to be caused by this line https://github.com/feathersjs/feathers-authentication/blob/master/src/socket/handler.js#L100 where it seems to wait for the token to expire and then log it out. This is actually quite useful for short token lifecycle (like several minutes) where we don't want the user to have access when the token already expired.

Unfortunately it seems that setTimeout will immediately run the callback when the timeout is too large. Probably because of this http://stackoverflow.com/questions/3468607/why-does-settimeout-break-for-large-millisecond-delay-values. I suggest using this https://www.npmjs.com/package/long-timeout or make some form of exception where in case the delay is very large, don't wait for expire time.

@marshallswain

This comment has been minimized.

Copy link
Member

marshallswain commented May 3, 2017

@asdacap thanks for figuring that out. Would you mind creating a PR with long-timeout?

@asdacap

This comment has been minimized.

Copy link
Contributor

asdacap commented May 8, 2017

Sorry for the late reply. Having issue figuring out a way to test it. Just created a pull request. Please review.

@ekryski

This comment has been minimized.

Copy link
Member

ekryski commented May 10, 2017

Looks to be closed by #499. Big round of applause for @asdacap. 👏

@ekryski ekryski closed this May 10, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.