My adventure in designing API keys

Re:My adventure in designing API keys by fabian2k on Wednesday April 15, 2026 @03:28AM (#47775780)

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.

[ Parent | on HN ]

Re:My adventure in designing API keys by iamflimflam1 on Wednesday April 15, 2026 @03:35AM (#47775816)

I would add the capability to be able to seamlessly rotate keys.

But otherwise, yes, for love of everything holy - keep it simple.

[ Parent | on HN ]

Re:My adventure in designing API keys by swiftcoder on Wednesday April 15, 2026 @04:42AM (#47776318)

> Plain old API keys are straightforward to implement

This is pretty much just plain-old-api-keys, at least as far as the auth mechanism is concerned.

The prefix slug and the checksum are just there so your vulnerability scanner can find and revoke all the keys folks accidentally commit to github.

[ Parent | on HN ]

Re:My adventure in designing API keys by vjay15 on Wednesday April 15, 2026 @05:14AM (#47776581)

yes this is the approach!

[ Parent | on HN ]

Re:My adventure in designing API keys by sabageti on Wednesday April 15, 2026 @04:44AM (#47776337)

We don't store it, in plain text right, store them hashed as always.

[ Parent | on HN ]