How does token authentication work with load balanced web services
We are using token based security on some of our ArcGIS Server web services and I'm trying to gain a better understanding of how they work. We currently have to use sticky sessions because we have load balanced services for redundancy and performance. However all the documentation I read (the below article for example) suggests that using token authentication should actually remove the need for sticky sessions. After all the reading I have done I am still not sure why this is the case.
If a user logs in and receives a token from one of our load balanced servers and the token is passed with every subsequent request, why should it not be necessary to ensure that the request ends up on the same server. How would the other server be able to authenticate the token? The only way I can think of based on my readings that this could be made to work without sticky sessions is to store the token signature in a central repository available to all the load balanced servers. Then again this is not that different from just storing the token itself which is the same as storing session information.
http://code.tutsplus.com/tutorials/token-based-authentication-with-angularjs-nodejs--cms-22543
Answer
The only way I can think of based on my readings that this could be made to work without sticky sessions is to store the token signature in a central repository available to all the load balanced servers.
Yes, that's correct. The linked article does show a persistent token store.
The only exception to this is if JWT's are used (also in the linked article), or a similar mechanism that doesn't store tokens server-side.
This is because even though the username is in the JWT that could be stored in the cookie client-side, the username is protected by a MAC. This Message Authentication Code hashes the username with a server-side secret. This secret can be shared amongst all load balanced servers, and rerunning the MAC algorithm can ensure that the client-side stored username has not been tampered.
In practise remember to always store an expiry date - otherwise your JWT would be vulnerable to replay attacks (e.g. a valid user saving their cookie value for later use when they may not have access as that user).