Their new key service signs tokens from a function without the private key ever appearing in your code or your environment variables. The verifier only ever uses the public key, through the standard.
- Vercel KMS signs tokens and arbitrary messages from a function.
- The private key stays inside the service, never entering the code or the environment variables.
- Verification works with standard libraries, with nothing Vercel-specific.
Anyone who has shipped something quickly knows how it goes. The key goes into an environment variable because it has to work today. Then it stays there.
And one day it turns up in a log, in a copy of the environment, or on the screen of somebody who shared their terminal.
Why this is more than convenience
A key that is not in your code cannot leak from your code. It is that simple, and that is exactly why it works.
The second part I like more: the constraint on what a given project may request. So even if somebody does manage to sign, they can only sign certain things for a certain environment.
There is a caveat, of course. The key is no longer with you, it is with a provider. You trade the risk of a leak for the risk of a dependency. For most teams the trade is worth it, but it is a trade, not a gift.
If you are on Vercel and rolling your own signing, go and look at it. If you are not, the idea is free to steal: let the key live in one place that your code only ever asks, without seeing.