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.

[harshsbhat]

@chronark In the dashboard, we can add a similar card to the prefix which is an optional field.

It can be encoded using JWTs with the option of NO expiration. So that the encoded token never expires.

We can keep the secret option either in the API settings or in the general settings. However, I think we should keep a different secret for each key as some people might want to keep different secrets for 2 keys in the same API.

So we will get a key like this prefix_key_jwt. Similarly, in API we can add a createKey field as encodedString: "userdata".

We can provide a very simple function in the SDK that separates the JWT from the prefix_key_jwt and then simply decodes it using the secret and JWT decode function.

The verify key should remain the same I think.

[chronark]

What is the benefit of using JWTs here? It would increase key length unnecessarily due to the header. They also include periods, which makes copying the key via double click annoying.

---

Can you elaborate what secrets you are referring to and why a user needs multiple?

[harshsbhat]

How can we encode the keys then? I am referring to the secret required for JWT to encode the user data. Also I had a question. As this is going to be a string we would need to limit the user at some point on how long the input string can be right? Otherwise the key will keep getting longer.

[chronark]

Ah you mean the signing key. Why do we need one per user or even one per key?

How will the signature verification work with individual signing keys?

[harshsbhat]

If the user wants some people to not access the encoded information then what's the solution for that? If they have different signing keys users can easily differentiate between who can decode some keys but not all keys.

[chronark]

Signing is different from encrypting

Signing only provides a way to ensure the authenticity of information, it does not prevent anyone from reading it.

Jwts or encoding in general does not encrypt data

[harshsbhat]

Give me some more time I am going to research a little more about this and then comeback. Seems like I lacked some knowledge here,

[harshsbhat]

I am sorry once again for wasting so much time without proper research

[chronark]

No worries, that's why I asked for an rfc before jumping into code