1) Adam Langley explains why SHA-3 exists and why it shouldn't be used:
It's not always a foregone conclusion that it scales better. I've seen people argue that when using ECDSA verification that's 4x longer than an in-DC RTT. Usually: DB kv lookups aren't even close to the most expensive thing your app does.
Generally: don't do encrypted tokens. If you must: don't do JWT for this. Just secretbox a thing and be done with it, or use PASETO[0].
By secretbox, I assume you mean NaCl's secretbox. Cool, thanks for the tips, and helping make the web a more cryptographically secure place.
> Generally: don't do encrypted tokens
Can you point to a RTFM on why not? I'm sure it's a big list of reasons but where can I read about the biggest one?
Because they cause more problems than they solve.
A lot of the implementations _aren't even faster_, but the laundry list of security bugs they have caused is very real. Suddenly you get to worry about irrevocable tokens in order to solve scaling problems you don't have.
A good intro is: http://cryto.net/~joepie91/blog/attachments/jwt-flowchart.pn...
2) Hrm. I guess maybe? As I understand it, the reason for a client token is to have stateless servers, so the server doesn't need to look up a valid token upon every request--which scales better. In my case, the API endpoint is for something that doesn't (and won't) get a lot of traffic, so I can probably get away with a 256-bit random token over TLS? Since it's over TLS, there probably aren't MITM attacks to sniff the token and replaying it--so it's probably ok? Are there other considerations I'm not aware of?