IMO the prefixed api key convention with a public portion and base58 encoding that i wrote about 2 years ago is so so much better than CD-key style API keys https://github.com/seamapi/prefixed-api-key
Making Beautiful API Keys
101–107 of 107 posts
Re: Making Beautiful API Keys
#102I guess this is an unpopular opinion given the existing comments, but I don't get it. They spent time and energy on this instead of writing features or fixing bugs and I don't think it matters at all. The only interaction I have with my API keys is copying them from one place to another. If I need to manually identify a key then putting the first or last few chars, whatever they are, in my working memory is more than…
Not only the development of the key format, but the post itself could have been 3 lines (with the leading example):
38QARV0-1ET0G6Z-2CJD9VA-2ZZAR0X
1. Use UUIDv7 as the base ID to leverage timestamps
2. Encode the ID using Crockford Base32 for readability
3. Add artfully placed dashes for aesthetics
[0] https://modernspecies.com/blog/post/understanding-the-200k-l...
Re: Making Beautiful API Keys
#103Re: Making Beautiful API Keys
#104Re: Making Beautiful API Keys
#105Earlier quoted context omitted.
I’ve made a library for that! https://codeberg.org/prettyid
There's a similar proposal called TypeID: https://github.com/jetify-com/typeid E.g.: user_2x4y6z8a0b1c2d3e4f5g6h7j8k
This is actually pretty good! And it seems to be compatible with my implementation (it’s also UUIDv7 and base32 alphabet is the same, but without mapping from OIL to 01).
Re: Making Beautiful API Keys
#106Earlier quoted context omitted.
Base32-Crockford doesn’t have 0 and 1 for this exact reason! (Seems uuidkey authors have decided to remove O and I instead, but the effect is the same) EDIT: I’ve looked it up and I was wrong! Crockford alphabet does use all digits (0–9), but doesn’t have O, I or L. When decoding, O is mapped back to 0 and both I and L are mapped to 1. Sorry for the confusion!
Given that API keys are likely to simply be copy-pasted, I don't honestly think this matters all that much. If you're have the risk to users confusing 0 and O, then you can't use either. Your users aren't going to know that you're running Base32-Crockford and that they'll only encounter 0 and 1, never O, I or L. We did a "password" generator, for people who made a purchase, but didn't want an account. To view an orde…
> Given that API keys are likely to simply be copy-pasted, I don't honestly think this matters all that much.
Yeah, I think it’s not that important for API keys particularly. It’s possible that some IDs would be spoken over a phone for example, but it’s probably rare.
> If you're have the risk to users confusing 0 and O, then you can't use either. Your users aren't going to know that you're running Base32-Crockford and that they'll only encounter 0 and 1, never O, I or L.
The way Crockford got around that was, OIL are allowed when decoding the string (and just replaced by 0 and 1 accodringly). So if used mistypes O in place of 0, it’s still going to decode just fine. I think it should work alright for stuff like license keys or “passwords” like in your case (although your solution works too!)
Re: Making Beautiful API Keys
#107Hey everyone. Thanks for all the discussion on the article. We wanted to respond to a few common themes:
0. Some folks don't care about API Keys, that's okay! But for those of you who did respond and do care, we are updating our design based on your feedback.
1. When we got to work on making our API Keys, we looked for an obvious standard but didn't find one. So we decided on our approach quickly and put together uuidkey in an afternoon. We knew it was not going to be everyone’s preferred design, but we wrote up the article to share our thought process as well as generate some marketing. We are happy to see that the article did well and we got feedback! :)
2. The ability to double-click to copy, which was lost with the addition of dashes, was more important to developer commenters than we thought it'd be (even if only needed once). We heard you, so we've already updated https://github.com/agentstation/uuidkey to support a `WithoutHyphens` option for the `Encode` function so you can generate keys without dashes.
3. Some folks were worried that our resulting key after encoding has fewer bits of entropy compared to the original UUID. The Crockford base32 encoding does not reduce entropy, it is a 1:1 mapping.
4. One quality piece of feedback pointed out that the UUID spec warns against using UUIDv7 (only 74 bits of entropy) and even UUIDv4 (standard 122 bits of entropy) alone for API Keys. We plan on still supporting UUIDv7 and UUIDv4, but will add additional entropy bits to follow the official recommendation.
4. Lots of commenters like prefixes, which make it easier to identify & search for keys (particularly to ensure they don’t get accidentally committed to a repo). We plan to add an option for that. Worth mentioning that a few folks pointed us to Github's auth token implementation that includes prefixes, which is a pretty great standard - https://github.blog/engineering/platform-security/behind-git...
Thanks again for reading, debating, and giving us some good advice! We want a product that feels good for developers to use. :D