My adventure in designing API keys
vjay15.github.io
My adventure in designing API keys
1–10 of 88 posts
Re: My adventure in designing API keys
#2Hello everyone this is my third blog, I am still a junior learning stuff ^_^
Re: My adventure in designing API keys
#3I don't like giving away any information what-so-ever in an API key, and would lean towards a UUIDv7 string, just trying to avoid collisions.
Even the random hex with checksum component seems overkill to me, either the API key is correct or it isn't.
Re: My adventure in designing API keys
#4Hey - this was a great blog ! I liked how you used the birthday paradox here.
PS : I too am working on a APIs.Take a look here : https://voiden.md/
Re: My adventure in designing API keys
#5[dead]
Re: My adventure in designing API keys
#6[deleted]
Re: My adventure in designing API keys
#7I 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!
Re: My adventure in designing API keys
#8I 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 technology. You do not want to conflate these ideas. JWTs would solve the stated database concern. All you need to store in a JWT scheme are the private/public keys. Explicit tracking of the session is not required.
Re: My adventure in designing API keys
#9I 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.
Re: My adventure in designing API keys
#10I 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!
The securify here comes from looking the key up in the DB, not from any crypto shenanigans.