I was intrigued by the discussion of this SO question as well as the accompanying blog post. I'm trying to better understand the mechanics of the two systems, and one of the questions I came up with is how much worse is it to have a token stolen vs. a session ID?
Here's what I understand so far, and please do correct me if I'm wrong:
A session ID is an opaque reference to actual session data stored on the server. It is safe insofar as it is random enough to not be guessed easily, and the data is safe because it is not directly accessible by or beholden to the front-end. The session ID is stored in a cookie to simplify authenticated requests.
An authentication token is a plaintext segment of JSON user data with a cryptographic signature that verifies the data's integrity. It is tamper-proof because of the signature, so no one can simply come up with their own token. The data it grants access to is safe on the server, except of course what is present in the token (which even then can be encrypted if need be). The token is also often stored in a cookie to simplify authenticated requests.
So here is what I do not understand. The way I see it currently, it seems just as likely that a token be stolen as a session ID, e.g. anyone breaking past my SSL and viewing my token would be able to view a session ID as well. Either event gives the attacker complete access to my account and all associated authorization. So in terms of the event likelihood and the resulting damage, is an authentication token really any worse than a session ID, as the article claims?
The one thing I could see potentially being worse for tokens is if the signing secret were somehow found out, in which case the attacker can do anything with anyone's account, rather than just mine. However I almost want to relegate this to the reasonable unlikelihood of someone first breaking RSA, in which case they can get past SSL, and then what good is a session ID anyway?