4 ms·
tptacek's survey was already mentioned here, but I think it should be more famous. https://fly.io/blog/api-tokens-a-tedious-survey https://fly.io/blog/api-token
by unscaled 1y ago
tptacek's survey was already mentioned here, but I think it should be more famous.
https://fly.io/blog/api-tokens-a-tedious-survey https://fly.io/blog/api-tokens-a-tedious-survey
Unfortunately, it seems like 99% of the industry decides which token to use based on Medium articles, LLM responses or how many unmaintained packages that implement this thing they can find on NPM.
JWT is mostly used as an access token, but for the vast majority of use cases it's a bad fit. If you've got low traffic no strict multi-region deployment requirements, random IDs are the best approach for you. They are extremely lean and easy to revoke. It's pretty secure: the only common vulnerabilities I can think of with this approach are session fixation[1] and timing attacks[2]. Both attacks are preventable if you take just a few simple precautions:
1. Always generate 32-byte session IDs using a cryptographically secure random number generator on authentication. (Never re-use existing session IDs for new logins)
2. Either use a cryptographic hash (e.g. SHA-256 or Blake2b) of the session ID a the database field used when querying sessions or make sure that the Session ID field is indexed with a hash-based index (B-trees are susceptible to timing attacks).
In cases where you really cannot use Session IDs, your service is usually big enough and important enough to use custom Protobuf tokens even a more special-purpose format like Macaroons. These formats give can be far more compact and give you full control on designing for your needs. For instance, if you want flexible claims (with most of them standardized across your services), together with encryption, you can use a combination of Protobuf and a libsodium secret box envelope.
[1] https://owasp.org/www-community/attacks/Session_fixation https://owasp.org/www-community/attacks/Session_fixation
[2] e.g. https://github.com/advisories/GHSA-cvw2-xj8r-mjf7 https://github.com/advisories/GHSA-cvw2-xj8r-mjf7
- lyu07282 1y agoI use JWT and a half dozen other standards, not by choice though, I wished I could do what you suggest it would simplify everything a ton, but I'm not going to roll my own multi-org/SSO/2FA auth platform. Needing those auth features is what made me use these standards not because my app is big, it's not it's tiny.
- slt2021 1y agosessionID is vulnerable to stealing cookies. Some games - if you lose your session cookie, you might as well lose your account and everything you have on it. you can of course bind sessionID to the IP address, but this is extra effort you need to put. in JWT land you can just put the IP addressed inside the payload and forward requests with non-matching IP to reauth and regenerate JWT for their new IP in case customer is roaming networks
- nh2 1y ago> or make sure that the Session ID field is indexed with a hash-based index Using a hash index instead of a btree isn't a 100% guaranteed solution because there may be craftable collisions (because e.g. postgres's index hash is not cryptographic) which cause fallback to linear comparison across the values inside the hash bucket: https://dba.stackexchange.com/questions/285739/prevent-timing-attacks-in-postgres/285770#285770 https://dba.stackexchange.com/questions/285739/prevent-timin... So hashing the ID before the DB lookup is better.