Self-Signed JWTs

Summary

Get a load of this (totally normalized) BS. "We have just the offering for you! Visit our website. Create an account. Verify your email. Create a project. Add your credit card. Go to settings. Create an API key. Add it to your password manager. Drop it in your .env file. Download our SDK. Import it. Pass your env var in. Never share your API key. Make sure you never commit it to source control. On the client, we have a React SDK. Make sure you use your publishable key for that. For the server, download our admin SDK. Use your secret key. Never mix the two up.” It’s truly wild to me what some of y’all will tolerate. Making your own API key Let me show you something… Did you know generating a JWK is stupidly easy? import { generateKeyPair, exportJWK } from 'jose' const keyPair = await generateKeyPair('ES256', { extractable: true, }) const publicKeyJWK = await exportJWK(keyPair.publicKey) const privateKeyJWK = await exportJWK(keyPair.privateKey) That’s it. Your JWK keypair is now effectively your own self-issued API key. No need to visit a website, make an account, verify your email, create a project, go to settings, create an API key, or copy it and use it. You just generated your own. How do we use this? Let’s see how we can get rid of secret versus publishable keys and separate client and admin SDKs. Who cares whether you’re on the client or server? If your app wants to authorize a privileged action, it should be able to do so without separate keys or SDKs. Here’s how to implement this: Store your app’s private JWK on the server Using whatever auth scheme you have, implement a function that returns whether to allow a given action Express privileged actions as claims in your JWT—if a privileged action is allowed, include the claim in the payload and sign the JWT with your private key Give your client SDK a function that reverse-proxies to your API, adding a signed JWT to the request’s Authorization header with any privileged claims you want to include Here’s what the...