2

I have a web app that makes use of node.js in the backend and angulajs on the front end.

Let's say I have a user who has the ability to login via multiple systems; I must allow multiple logins.

I am making use of jsonwebtoken module to generate token for a user after he is authenticated and that is saved in the redis and the token is sent back to the user which is saved in his cookie.

Let's say I have expiration time of 5 hours on both the cookie and the token (redis).

How can I plan the whole thing out?

Even if I use a set to save multiple tokens in redis then I cannot actually add expiration time on each value. And on top of all that I must accommodate refresh tokens so that if a user is using system regularly then his token stays active.

Improve this question

    2 Answers 2

    Reset to default
    1

    Associate the token with the source IP address of the request in addition to the username when saving it to redis and when looking it up while authenticating a request. Remember to handle the case where you have a cookie but it doesn't match the token associated with the request's source IP address, authentication should fail in that case.

    Another option would be to invert the mapping and use the token value as the key in redis, with the username and other associated information as it's value. That would allow for multiple logins, each with their own token, and for changing IP addresses. The problem with allowing the IP address to change is that anyone who can steal a token for a valid login session (say by malware on the victim's computer) can use that token to bypass the login process until the token expires. That's why so many sites IP-lock their authentication tokens, and if they detect a change in IP address they demand re-authentication to continue with the session locked to the new IP address.

    Improve this answer
    4
    • I thought of using IP as a field for authentication but then how would I handle the dynamic IPs that generally people have.
      – Gandalf the White
      CommentedJun 18, 2016 at 10:23
    • DHCP-assigned IP addresses don't usually change over the timeframes involved in sessions. In fact, because DHCP prefers renewing an existing assignment over assigning a new address a computer's address doesn't change often over the long term. Normally the only things that trigger a change are the computer being turned off for several days and then booted or the ISP changing/upgrading it's hardware in the area.
      – Todd Knarr
      CommentedJun 18, 2016 at 17:02
    • @ToddKnarr You have not considered the case where user is on mobile and may move from Wifi to using cellular network in which case the IP address will change but the user should be allowed to continue the existing session.
      – ARau
      CommentedFeb 13, 2017 at 2:31
    • The alternative to that would be to reverse the mapping, make the redis key the token value and store the username the token was issued to plus other associated information. That'll allow for multiple logins and for changing IP addresses. The problem is this makes it possible to copy the token (usually that involves malware on the user's machine) and use it from another system to gain access without having to crack the account's password. That's why IP-locking is more common, and if the user's IP address changes they have to re-authenticate.
      – Todd Knarr
      CommentedFeb 19, 2017 at 19:41
    0

    OAuth 2.0 protocol flow (RFC 6749) has addressed this issue having to distribute long lasting tokens while minimizing updates to the datastore. It calls for 2 different tokens, an short lived access token which does not need to be stored and a long lived refresh token which can be stored (to allow for revocation). The flow is depicted here:

    OAuth2 token flow

    In your case you would issue one refresh token per user which is signed by a secret key and then issue an access token which is also signed for each login session. The advantage of this approach is that the short lived access tokens (5 to 10 mins) can be used for stateless verification on every request (since the user will send it as the cookie or in the header). The refresh token is long lived (5 hours) which is stored in redis and is renewed with an updated expiration time whenever a client asks for a new access token. This ensures that refresh tokens are updated only when access tokens expire (every 5 to 10 mins max in this case). This provides a good solution by providing security (short lived access tokens) and avoiding database calls (long lived refresh tokens need to be updated only when access tokens expire).

    Improve this answer
    4
    • Short Lived access token will be stored in memory such as redis as well right. And if I'll have to refresh the main token then I need to make a separate call from my client to server - given that if that request is processed in normal authentication channel then it's of no use. In that case what'll happen if let's say a client logs in then closes the web app or kills the android app and then after an hour or so he has expired short lived token and a okay long lived token.
      – Gandalf the White
      CommentedMar 27, 2017 at 13:22
    • There is no need to store the short lived access tokens since the client will be storing it and sending it in the header on every HTTP request. When the logged on user closes the app and tries to login an hour later, it will call the "refresh service" on the Authorization server with the refresh token in the header which will check for session expiration and if the session is still valid will return a new access token + new refresh token with a new expiration. You will need to call redis here to update the refresh token with new expiration time.
      – ARau
      CommentedMar 27, 2017 at 18:31
    • How will you authenticate the short lived token? Via decrypting it?
      – Gandalf the White
      CommentedMar 28, 2017 at 8:06
    • Plus the main problem that I am trying to address is handling multiple tokens for same user. The last paragraph. The solution you are proposing is just another way to cater to the problem.
      – Gandalf the White
      CommentedMar 28, 2017 at 8:10

    Start asking to get answers

    Find the answer to your question by asking.

    Ask question

    Explore related questions

    See similar questions with these tags.