[jongjong]

These are all bad arguments which I've heard many times. Once your front end is compromised with an XSS attack, it doesn't matter if you're using cookies with session IDs or JWTs... The attacker can use their malicious script running in the user's browser to make calls to your back end server on behalf of the user since the session ID would be sent along with the request inside the Cookie header.

The only added 'protection' of the session ID with cookie approach is that it forces the attacker to perform the attack in-situ inside the user's browser... But that's the best place for the attacker to perform the attack from anyway so it adds no value at all. It wouldn't make sense for the attacker to steal a JWT and then use it to make a request from their personal machine using their own IP address...

Note that httpOnly flag when using a cookie also doesn't add much value for the same reason. The hacker doesn't need to know what the session ID is in order to be able to fully compromise an account and do whatever they want with it.

The main drawback of JWT is that you can't reliably revoke a token after it has been issued. The solution for that is a combination of:

1. Set a short expiry date.

2. Have some kind of 'isDisabled' (or similar) field on the account (or keep a blacklist of account IDs) which allows you to instantly disable a compromised account so it doesn't matter whether or not they have a valid JWT token.

Although the second point means you will need to perform a DB lookup of the account (which some would suggest defeats the purpose of JWT), it's a lot simpler to lookup an account record than having to keep track of a session object and remember to clean it up when the user logs out (while also handling all possible server failure/restart scenarios which would otherwise leave behind stale sessions); managing sessions on the back end can be especially challenging in multi-process and multi-host applications... This is where JWT shines.