I've a token based authentication system (REST) that I inherited for an iOS app (can't change), and I've to re-use the same authentication web api system (that I can change to adapt for the web requests while still accommodating iOS app).

Here's how the authentication system works.

  1. username, password -> if valid a token is returned to the user and also saved to the database

  2. getNewToken -> passes the old authToken, web api verifies from the table, issues a new token, updates the database table

1 is triggered by user login while 2 is automated interval based call every 15 minutes by the iOS app (I guess to keep the session alive, like heart beat)

Now when user is on the web and logs in, I call #1 to get the token but then if user is already on the device, the old token at device won't work because it got updated on the server as a result of user signing on the web.

This makes me wonder and in the light of above scenario my question is how multiple sessions are handled using authentication token system out there in real life, for instance I could open gmail or Facebook in two different browsers and both sessions are maintained (I'm not sure if they are using token based system or some other but let's say they are for an example). Please advise.

  • You need to manage login tokens per user + device and not per user only.
    – genichm
    Commented May 12, 2015 at 19:06
  • I see, so I guess I've to introduce another table, let's say token(id, authenticationToken, user_id), where user_id is the foreign key to the user table, and manage sessions from there, please confirm. Commented May 12, 2015 at 19:10
  • Yes if id is id of the device cause you need to store device id in some place. If you can install programs on the server better to store login tokens not in database but in some external key value storage like redis or memcached, if you can do it of course.
    – genichm
    Commented May 12, 2015 at 19:16
  • ah, no, the id was PK AI, in that case table would be token(id, deviceId, authenticationToken, user_id), please enlighten more on the deviceId, where do I get this deviceId (both for browser and iOS app) information. I like the idea of key value storage, I can use mongodb Commented May 12, 2015 at 19:21
  • Mongodb stores data on disks and not in memory, so it is litle bit slower than Redis. Another benefit of using redis is ability to define key lifetime, it means that you can kill ghost keys without coding, but mongodb is good too just remember that you going to have many tokens that not in use. Key may be your login token. Device id of android or ios can be generated on the device, it can be some guid for example, on android exists android id that is unique string. And you can generate some id for browser on login and to store it in cookie.
    – genichm
    Commented May 12, 2015 at 19:39

1 Answer 1


Yes if id is id of the device cause you need to store device id in some place. If you can install programs on the server better to store login tokens not in database but in some external key value storage like redis or memcached, if you can do it of course.

  • question, what do I use device_id for when it comes to statistics? it's going to be some guid that I won't be able to understand, second do I've to check on the server that both device_id and token matches to retrieve user_id Commented May 12, 2015 at 21:19
  • I'm studying more on REDIS, and going to implement it, can you please help. so I'm going to have authToken, user_id as key value pair, tokens['abc'] = 1, tokens['def'] = 2, tokens['xyz'] = 3, wondering where device_id comes in this picture for the key/value pair Commented May 12, 2015 at 23:23
  • Device id for example can show you how long user uses your program from same device, or how many devices has the user. In REDIS you can store data this way - key is your authtoken and value some complex data about the login. It may be some data like device id, user first name and... Value can be stored as, for example, json string that you can deserialize or some binary data. It may work this way: request coming -> get authtoken from that request -> find record in redis by authkey -> if record exists deserialize value. Then on output you will hold base data about user without querying database
    – genichm
    Commented May 13, 2015 at 3:13
  • Thanks man for changing my whole perspective about things, I learned redis and changed my nodejs code overnight, and all my token based authentications are going through redis. Only hitting the database for username/password. auth validation responses are amazing under 10ms, managing authToken in the db was pain, for every renew of token, I'm deleting the old one (learned from twitter toy clone in php) Commented May 13, 2015 at 16:30
  • however, in your earlier comments when you said ghost keys, scenario 1 -> iOS app is logged in all the time, if logout I'll delete the auth key on redis, same with browser end. save the token in local storage and renew when website was accessed to ensure login validity. my question is when is the case when I'll end up with too many ghost keys? Commented May 13, 2015 at 16:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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