I'm trying to implement authentication and session management for a microservice. In order to do the process RESTfully, I understand that I'll need to use some kind of token-based authentication to avoid tracking client session data on the server. The following quote from this answer on the Information Security Stack Exchange nicely sums up my understanding of the implementation:

In Token-based Authentication no session is persisted server-side (stateless). The initial steps are the same. Credentials are exchanged against a token which is then attached to every subsequent request (It can also be stored in a cookie). However for the purpose of decreasing memory usage, easy scale-ability and total flexibility a string with all the necessary information is issued (the token) which is checked after each request made by the client to the server.

From this, I understand how stateless session maintenance is advantageous for scalability, and flexibility as explained. But it seems to me that this leaves the application exposed to some serious problems:

  1. If a hacker somehow intercepts the credential exchange HTTP REST call, they could execute replay attacks on the server get all the information they want.
  2. In fact, since the session token is stored on the client side, couldn't a hacker just retrieve the requisite information from LocalStorage/SessionStorage by debugging the app? Or by monitoring the incoming and outgoing HTTP calls using dev tools? If they get the required token information (even encrypted token information), they could simply start faking REST calls to the server from another window and get all the data they want!

Replay Attack Wikipedia image

  1. Finally, even if you do give the client a session token, wouldn't the server still have to authenticate that token? In effect, the server would have to maintain session tokens to user mappings...but doesn't that defeat the purpose of a stateless REST-based architecture?

Maybe I am seeing these problems because there is a gap in my understanding. If that's the case, I'd like some clarity of the basic concepts. If not, I'd like to know if there are any techniques to address these specific problems.

2 Answers 2


This answer may help you in terms of replay attacks at the network level. The use of a "nonce" can also help protect against the same semantic request being made multiple times by the same client.

In terms of a Man In The Middle (MITM) intercepting a hash and replaying it in place of a password, it is true that this is possible, but equally this is possible when state is stored on the server and a plain session token cookie is being exchanged, but should be made more difficult in both cases by using HTTPS with strong configuration (strong ciphers, EDHC, modern protocols, HSTS with preloading, possibly HPKP. You may use https://www.ssllabs.com/ssltest/ to test your configuration.

Using secure http only cookies can also help protect against accidental state disclosure as might a CSP to prevent unauthorised scripts trying to perform exfiltration.

Processes, like that used in JWT, might help protect you against the concern of a malicious client opening up their local storage or cookies and modifying them (e.g. someone trying to change their local state that would be sent to the server). By utilising public key infrastructure (PKI), providing the private key is kept safe, this technique is effective in validating a digital signature (ensuring client state wasn't changed when reading it on the server). This is as you point out in your question part 3, the server doesn't need to necessarily map the client token to validate it, it "just" needs to validate the HMAC to ensure message integrity before trusting the data).

On a more broad level, being strictly restful in maintaining client state on the client, whilst brining many benefits in terms of scalability does bring some challenges, like those you mention here, and in many cases you can achieve acceptable scalability with server side managed state replication and partitioning to isolate faults to a smaller subsection of your user. E.g. think about Redis and managed hosting like AWS Elasticache which might make your life easier. When state is managed exclusively on the client it can become harder to do things like revocation and premature expiration.

I hope that this helps in some way,


Q: 1-2 Yes, it might happen. Hackers can impersonate other users if they managed to steal their authorization tokens. However, it would take them (usually) to get access to the user's client.

Regarding interprocess communications, if server-client communications are secure (encrypted), no man-in-the-middle will provide attackers with sensible data. That's why TLS is so important in distributed systems.1

Back to the stolen tokens, to mitigate this vulnerability we often make tokens short-living. Tokens expire eventually, forcing clients to request the authorization token again. Some security implementations use refresh tokens, others force clients to do log-in again.

On the server side, there're some measures we can implement as well, as for instance, we can expire tokens prematurely or we can implement blacklists or/and whitelists.

Q: 3 server will validate the token in every single request. Looking for it in the DB, decoding its content, sending the token to some kind of authorization service, etc. As we would with any other credentials. It takes storing the token somewhere of course, but tokens are not sessions. They don't hold the client' state, the identify users and grants and, sometimes, the issuer of the token too.

As for session tokens, if server-side is purely stateless there's nothing to preserve regarding client-side state, there's no session at all to identify. The same authorization token acts as a session token; as soon the token expires, the session on the client-side might do it too.

1: There're other attack vectors like cross-site scripting attack, potentially harmful but "relatively" simple to prevent.

Your Answer

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

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