Anyone got a minute to explain to me exactly why JWT's are bad? In the browser, yes, if you're vulnerable to XSS, someone could grab your token. But for authenticating against an API? HTTP only cookies would work for the browser app in this case, so should I use stateful tokens to authenticate against my API from something that's not a website as well? I see way too much conflicting info and I don't have the skill to verify cryptographic properties.
Short expiry time and rotating tokens sound like something you should be doing in either case. If someone grabs your token, then it doesn't matter whether or not it's stateful or not, you'll have to invalidate it either way by either re-signing a new token with, for example, a changed password, or by removing it from your session state. What if you used a short JWT as an HTTP only cookie? 4096 bytes sounds like a lot of data, makes sense to not send such a large token with each request anyway.
Or just don't use stateless tokens at all and make that extra call to verify a token after the request is made?
I guess I'll use Redis for session management instead of JWT then.
@talon depends on what the tokens are for. It's not straightforward to XSS a bank, at least as far as I know.
@bulkington I'm not looking at it from an attackers side. I'm developing a web app and looking into ways to handle authentication and authorization both for the web frontend and the API, which are separate things.
What if you used a proxy for your web app to store the tokens, keep all it's state contained and off the client, while providing tokens to people implementing your API that may have better means to store the tokens securely? If you have that kind of access to a device then certainly you could be doing much worse than just steal someone's tokens?