Encoding data into plaintext keys

[chronark]

Preliminary Checks

• [X] I have reviewed https://unkey.com/docs for existing features that would solve my problem

• [X] I have searched for existing feature requests: https://github.com/unkeyed/unkey/issues

• [X] This issue is not a question, general help request, or anything other than a feature request directly related to Unkey. Please ask questions in our Discord community: https://unkey.com/discord.

Is your feature request related to a problem? Please describe.

Right now a key bears no information at all and requires a call to unkey before knowing about the caller identity. If we could extract the caller's id from the key without doing a network request, we could run tasks in parallel to the key verification and lower the overall latency of the handler function.

Describe the solution

Encoding any kind of information into the plaintext key, requires that we cryptographically sign everything to prevent anyone from forging encoded data in keys.

When creating new keys, the user may choose to add data that will be encoded and be part of the raw plaintext key. The downside is that keys may become much longer, as they include arbitrary data as well as a signature.

When verifying a key, we can provide functions in the sdk to extract said data without doing a network request. The user must still do a verification afterwards to ensure the key has not been disabled or exceeded limits, but they can start running some networked tasks (database lookup etc) in parallel to the verification.

Imported, or older keys will not retroactively be changed, unkey's customer is expected to ask their users to rotate their keys.

Describe alternatives you have considered (if any)

JWTs or any form of expiring token, but they're annoying to deal with from the end user's side as they need to refresh them constantly.

Additional context

No response

[linear[bot]]

ENG-1255 Encoding data into plaintext keys

[harshsbhat]

Sounds like a promising and performance-enhancing feature. So if I am not wrong this one will also require permissions to encode_key and decode_key right?

[chronark]

Performance in the sense of allowing the user to act sooner, yes

I don't think we need extra permissions for this. How are you arriving at that conclusion?

[harshsbhat]

Yeah, you are right! No need for special permissions. How do you think we can tackle the problem of token expiration?

[chronark]

What problem are you referring to? Our keys are already capable of expiring

[harshsbhat]

What problem are you referring to? Our keys are already capable of expiring

I am referring to the problem that if we enable encoding for the keys using something like JWT. It is gonna cause expire after a while. How do we tackle that ?

[chronark]

We don't expire them like JWTs do, the validity of a key is determined by us, we do not store an exp field or similar within the encoded key.

[harshsbhat]

We don't expire them like JWTs do, the validity of a key is determined by us, we do not store an exp field or similar within the encoded key.

I am talking about the Encoding. We don't have that feature yet, right? If so, can you please send me the docs? I was assuming we don't have this encoding feature and if we are implementing it how we can tackle the problem of expiration

[chronark]

It does not exist yet.