Security difference between web tokens and message signing

Question

I'm seeing two different types of authentication being widely used, with one being far more complex than the other. One are the simple session ID tokens used in most websites (user sends login info, receives a token, and passes that token with every future request as authorization). The other is the HMAC signing used in some APIs (uses public/private keys for message encoding).

From the outside, the HMAC method looks far more secure. Messages can't be forged or duplicated, you know the message is always authentic. However it requires a lot more work to package up and sign every request, and requires a way for the client to gain access to the public/private keys to use for signing.

By contract, tokens have been around a long time, and appear to be relatively secure if used properly (only transmit over SSL, pass back a new token with each server response, record the last token used, etc.), and they don't require any key handling.

So why does HMAC signing exist on the web? Are there scenarios that simple session tokens can't protect against? If so, why are tokens still in use?

Tokens are a lot easier to design a thin client around when I don't have to find a way to pass keys around, but I also don't want to shoot myself in the foot by overlooking any inherent security holes.

Answer 1

Signed tokens are useful in the situation where there is a separation between the server that logs you in and the server that provides the service. The server that logs you in provides you with a token, signed with its private key. The server that provides the service doesn't need to know that key, can check with the login server's public key to ensure it is valid.

Simple sessions are great for single server setups, but can be more challenging (though not impossible by any stretch) to scale, since the session id needs to be looked up server side in order to validate it - a session id is valid if and only if it is in the server's active session list. That means that if a session is created on one server, there needs to be extra work for a separate server to recognize it. There are frameworks for cross-server sessions, but it isn't the default in most cases.

If you do do tokens, you need to ensure that all tokens you accept are appropriately signed and that you check that they are exactly as you expect. There have been some vulnerabilities noted that happen when you are not rigid about the algorithms you accept on your site - you need to go beyond the JWT standard and actually enforce your own stricter standard in general. (I disagree with the conclusion of that article, but you should be aware of it if you do JWT or similar tokens)