Add logout function to invalidate the accesstoken

[jannyHou]

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.

[dhmlau]

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]

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]

@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:

1. Set a reasonable expiration time on tokens
2. Delete the stored token from client side upon log out
3. Have DB of no longer active tokens that still have some time to live
4. Query provided token against The Blacklist on every authorized request

[travis-infosec]

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]

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]

Since making validate/invalidate tokens pluggable is in loopback-next and 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.