> we search our database for short_token and hash(long_token).

Sounds like some salt should be used here. Search the DB for short_token, then use the discovered salt to check the "password".

Author here: I was curious what HN would think of this token style, we're currently using it for getseam.com . I think it has a lot of advantages over other token styles (e.g. double-click to select, standard alphabet, compatible with secret scanning). Although this is a typescript library, we originally designed this API key for use in Ruby on Rails and the pattern should be fairly portable.

I wasn’t too sure based on the docs:

What parts of tokens does the server store in the Database (everything but the raw long token I think?)

What is sent to the consumer, and what do they need to send with the request?

Why base 58? I've never even heard of base 58.

  // Store the key.longTokenHash and key.shortToken in your database and give
  // api.token to your customer.

I created a similar project recently! Main difference is that I use base64 to encode unique Snowflake IDs, which are timestamped: https://github.com/hopinc/pika :)

Very cool,

I use something similar but a fixed length for the prefix and uppercase

Basically a copy of stripe tokens

Nice work! May I inquire as to the design decision behind storing a hash of the long token server-side for verification of the long token, versus digitally signing the short token plus a nonce and including this signature in the API key (instead of a long token), as some other API key schemes do?

Both are valid approaches of course, I'm just interested to hear your thoughts on the relative tradeoffs.

Hey, cool idea. I like it. I made a Go implementation for fun/practice - https://github.com/joemiller/prefixed-api-key

I like it. I'm not sure that "short token" is the right term for that - perhaps "token id". Also the only occurrence of "it's" in the README should be "its": https://brians.wsu.edu/2016/05/19/its-its/

Edit: Actually, the short token is more than just a token ID - it's also required, right? Perhaps replace:

   When we receive an incoming request, we search our database for hash(long_token)

   When we receive an incoming request, we search our database for hash(long_token) and short_token. A token can be blocklisted by its short_token.