Repository navigation
Add logout function to invalidate the accesstoken #36
Description
Description
The logout function for jwt strategy is missing in PR #26, we should add it in the user controller by invalidating the accesstoken.
JWT authentication is stateless, which means the best way to invalidate the accesstoken is removing it from the client side. IMO the best way to invalidate it in a LoopBack app, is to remove it from the explorer when we finish story loopbackio/loopback-next#2205.
More discussion are welcomed. cc @strongloop/loopback-next
Acceptance Criteria
- Add the logout endpoint in user controller by invalidating the JWT access token.
Reacted by L. Bete and Riplar
Activity
dhmlau commentedon Feb 15, 2019
Maybe I'm missing something, I'm not sure how the access token can be invalidated by removing it from the client. The application and LB has no control on the client side, so it cannot be the way to invalidate the token.
Is it possible to have an expiry date/time in the token if we don't have it already? If the user logs out, the token expiry value will be set to a past time, so that it is always expired when it is being validated next time. I'm thinking along the line of this: https://stackoverflow.com/questions/28759590/best-practices-to-invalidate-jwt-while-changing-passwords-and-logout-in-node-js/28804067.
joeytwiddle commentedon Feb 15, 2019
You can't change the expiry time of a token that has already been issued. Changing anything in the token is essentially issuing a new token. The original token will remain valid (which is troublesome if it has been stolen).
Your concern is shared by others @dhmlau. I have been somewhat convinced by this argument that JWTs are not suitable for sessions: Stop using JWT for sessions - by joepie. But I would be happy to be corrected!
If a token has been issued and is in-date, but you really want to prevent it from being used again, then you need to add it to a server-side blacklist, or alternatively maintain a whitelist of valid tokens. (The latter is basically equivalent to session tokens/cookies.)
But if you are happy to assume that the token has not been stolen then just destroying all copies of it (i.e. removing it from the client side) should be sufficient for a log out, as jannyHou suggested. That is just a client-side operation.
dhmlau commentedon Feb 20, 2019
@joeytwiddle, thanks for your info! Reading into it some more and found this article (https://medium.com/devgorilla/how-to-log-out-when-using-jwt-a8c7823e8a6) as well. It suggested a few things we could do if we really want to log out:
travis-infosec commentedon Apr 29, 2019
You can put the invalidated-but-not-expired token JTIs on a REDIS blacklist, with an expiration time of the token's expiry. This is self-pruning. Just make sure that none of the systems allow a window after the expiry where they can do stuff. https://github.com/sirwolfgang/jwt_keeper
dhmlau commentedon Jun 10, 2019
Discussion with @raymondfeng @jannyHou @emonddr:
In logout endpoint to call the invalidate function, we can make the invalidate pluggable (expose as extension point) for users to implement themselves. We're not going to provide a generic implementation for invalidating tokens.
dhmlau commentedon Jun 10, 2019
Since making validate/invalidate tokens pluggable is in
loopback-nextand we have a similar issue loopbackio/loopback-next#2057 to keep track of it. I'd like to close this issue in favor of loopbackio/loopback-next#2057. Please continue the discussion over that. Thanks.