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.