7

This question follows my previous one: How to securely keep my users signed in with refresh tokens?

What I got from this previous question, is that we need:

  • short-lived access tokens
  • long-lived one-time refresh tokens

Refresh tokens are persisted in DB alongside users in a 1-1 relationship (1 user = 1 refresh token). Each time a refresh token is created for a user, it replaces the previous user's persisted one (if any). This allows possible hackers to have only a limited window to do their stuff:

  • user signs in and receives access token A1 and refresh token R1
  • hacker achieves to get those tokens somehow
  • access token A1 reaches expiration, so the hacker gets new access/refresh tokens A2/R2 thanks to the stolen refresh token R1: newly created refresh token R2 (that only the hacker has) replaces the previous one R1 in DB (the one the user has)
  • user fails getting a new access token because his refresh token R1 no longer exists, so signs in again and get new access/refresh tokens A3/R3: newly created refresh token R3 (that only the user has) replaces the previous one R2 in DB (the one the hacker has)
  • hacker's access token A2 expires, but cannot get a new one because refresh token R2 no longer exist: needs to steal the tokens again (supposed to be tough to do of course)

What I'm wondering here, is how to allow a user to connect from multiple devices with this mechanism? For example, if a user signs in with two different laptops, then refresh tokens will always erase each other... Any clue?

  • Do you absolutely need to use refresh tokens to keep users logged in? – Limit Aug 9 '17 at 16:33
  • @Limit Well, as refresh tokens seem to be the common approach, this is what I studied, but I'm open to other solutions as well :) – sp00m Aug 9 '17 at 16:37
3
+25

In my opinion the question you're asking now is not really regarding security anymore, instead it's more focused on the implementation of a concept. You have already established that refresh tokens makes it harder for attackers and it appears like you have a working implementation. From what you are describing, you are making use of a custom solution and not something like an OAuth2 library implementation that will provide this functionality to you.

What you now need to decide is if you want multiple device authentication from the same user account. If you do not want users to sign in from multiple devices on one account, congratulations, your solution is already working. They will be logged out from the old device soon since it will not contain the correct refresh token after a timeout.

If you do want to provide users the ability to sign in from more than one device on the same account, you unfortunately require a few changes. A possible solution is to add a device identification field in your database and issue a refresh token per device.

  • This sounds particularly interesting: add a device identification field in your database and issue a refresh token per device. Could you detail your thoughts a bit about this? How would this be handled without letting hackers registering their own device? – sp00m Aug 18 '17 at 15:05
  • You can use a banner staying 1 week saying "A new device was registered, if it's not you, you should remove it and change your passphrase. This banner will stay for 6 more days". – A. Hersean Aug 23 '17 at 7:56
  • PS: you should also check if Google doesn't have patents on this idea of them. – A. Hersean Aug 23 '17 at 7:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.