My adventure in designing API keys

Post by rrr_oh_man » Wed, Apr 15, 2026, 8:09 AM UTC

notpushkin wrote: post #14

bob1029 wrote: post #8

I don't understand the need for this level of engineering. It appears we are going for an opaque bearer token here. The checksum is pointless because an entire 512 bit token still fits in an x86 cache line. Comparing the whole sequence won't show up in any profiler session you will ever care about. If you want aspects of the token to be inspectable by intermediaries, then you want json web tokens or a similar technol…

> The checksum is pointless because an entire 512 bit token still fits in an x86 cache line I suppose it’s there to avoid round-trip to the DB. Most of us just need to host the DB on the same machine instead, but given sharding is involved, I assume the product is big enough this is undesirable.

Post by swiftcoder » Wed, Apr 15, 2026, 8:42 AM UTC

fabian2k wrote: post #9

usernametaken29 wrote: post #7

I know sometimes people just like to try things out, but for the love of god do not implement encryption related functionality yourself. Use JWT tokens and OpenSSL or another established library to sign them. This problem is solved. Not essentially solved, solved. Creating your own API key system has a high likelihood of fucking things up for good!

You don't need any encryption or signing for API keys. Using JWTs is probably more dangerous here, and more annoying for people using the API since you now have to handle refreshing tokens. Plain old API keys are straightforward to implement. Create a long random string and save it in the DB. When someone connects to the API, check if the API key is in your DB and use that to authenticate them. That's it.

Post by pdhborges » Wed, Apr 15, 2026, 8:45 AM UTC

Post by vjay15 » Wed, Apr 15, 2026, 9:09 AM UTC

bob1029 wrote: post #8

I don't understand the need for this level of engineering. It appears we are going for an opaque bearer token here. The checksum is pointless because an entire 512 bit token still fits in an x86 cache line. Comparing the whole sequence won't show up in any profiler session you will ever care about. If you want aspects of the token to be inspectable by intermediaries, then you want json web tokens or a similar technol…

Post by vjay15 » Wed, Apr 15, 2026, 9:11 AM UTC

notpushkin wrote: post #11

vjay15 wrote: post #2

Hello everyone this is my third blog, I am still a junior learning stuff ^_^

Hey, welcome to HN! Reading “hex” pointing to a clearly base62-ish string was a bit interesting :-) Also, could we shard based on a short hash of account_id, and store the same hash in the token? This way we can lose the whole api_key → account_id lookup table in the metashard altogether.