Interesting, so instead of OpenAI giving me an API key, I give them a public key, which they register. Sounds like what we already do with GitHub. I like it.
deathanatos · 5m ago
Which, unless I'm missing something, undercuts the entire article? The private key, in the generated keypair, is the thing that you can then never commit to your VCS.
When you "register" the public key with whatever the relying party is, you're also likely going to bind it to some form of identity, so you can't leak this private key to others, either. (And I'm curious, of course, how the relying party comes to trust the public key. That call would seem to require its own form of auth, though we can punt that same as it would be punted for an API key you might download.)
PantaloonFlames · 1h ago
Yes.
and it’s easy to do keypair generation in the browser using subtle crypto. That API doesn’t provide jwk generation, but seems like it would be relatively easy to do even without the jose module. And the browser cab “download” (really just save) the keypair using the Blob API. Keys need not leave the browser.
An api developer portal could just offer
- generate a new keypair?
- upload your existing public key?
…As a choice. Either way the public key gets registered for your account.
The end. Easy.
johncolanduoni · 1h ago
This is actually how GCP has always done service account authentication. A GCP service account key is an asymmetric keypair and Google stores the public key. AWS is somewhat similar, but they use an symmetric HMAC so they store the same secret key you use.
danscan · 1h ago
It's interesting to imagine taking the pubkey as identity concept to its full extents in situations like this, for example if you could create a cloud account, spin up resources, and authorize payment for them all programmatically without having to enter payment details on a form (because your keypair can authorize payment with the whatever payment method you use)
lokar · 1h ago
Even better if they would take a private CA cert.
esseph · 1h ago
This is similar to ssh key auth. (Pubkey, privkey)
beckthompson · 4h ago
Github has a cool little article on making JWTs for their API. Very useful!
I feel like I’m not understanding the target audience for this post: are there people/companies out there specifically paying other companies to be their key-holding party for JWT issuance purposes? I know about SSO providers of course, but that’s several layers of abstraction up.
(Maybe my confusion here is that these JWTs are being described as self-signed, as if there’s a JWK PKI cabal out there, like the bad old days of the Web PKI. There isn’t one that I know of!)
danscan · 2h ago
The key distinction I am getting at is: self-signed as in “signed with a self-issued key pair”, as opposed to using an API key/credential that has been issued to you
jauntywundrkind · 1h ago
The model here feels not entirely dissimilar to Passkeys? Both are user provided auth tokens??
[Ed: allegations that the following is inaccurate! Probably checks out? Yes I meant the browser not the domain bound part, that seems solid.] Pity that Passkeys are so constrained in practice by browsers, that using them pretty much requires you trust the cloud providers absolutely with all your critical keys.
johncolanduoni · 1h ago
They're not constrained that way at all. The communication between browsers and various passkey-holding software and hardware is an open standard. There are open-source apps that can hold and sync passkeys. I don't know why everyone keeps repeating this obvious falsehood.
danscan · 1h ago
Not sure which way of constraint you're referring to, but WebAuthn credentials are bound to a domain via Relying Party ID.
There's a proposal for cross-domain usage via Related Origins, but that scheme depends on the authority of the relying party, meaning you can't say "I'd like to be represented by the same keypair across this set of unrelated domains"
johncolanduoni · 1h ago
I was referring to this:
> Pity that Passkeys are so constrained in practice by browsers, that using them pretty much requires you trust the cloud providers absolutely with all your critical keys.
Passkeys are not constrained so you have to trust cloud providers or anyone else with all your critical keys. The key is resident in whatever software or hardware you want to use, and anyone can create passkey software or hardware that will work with Chrome etc. I'm talking about (and I'm pretty sure the OP was referring to) the other side of WebAuthn: where the credentials surfaced to JavaScript via WebAuthn actually come from and how the browser relays requests that a challenge is signed.
danscan · 1h ago
Ah, yes I agree
danscan · 1h ago
Yeah, I am sort of a fan of Passkeys in principal, but they are domain bound (you can't use them across domains).
I wish there were something built into browsers that offered a scheme where your pubkey = your identity, but in short there are a lot of issues with that
JohnMakin · 3h ago
is the author suggesting allowing the client to set their own claims and using that to auth whatever action they are going to take? I have to be misunderstanding what they are saying - that sounds fraught with risk
danscan · 3h ago
(Author here) The JWT signer should be the authority setting claims, so if your server is the authority and the client is untrusted, the server can provide the client a pre-signed JWT with the claims it needs, and the client can send that along with requests to the API.
But this scheme is flexible. You could also have the client send "requested" claims for the server to consider adding if allowed when getting a JWT.
You could also reverse-proxy client requests through your server, adding any claims the server allows.
danscan · 3h ago
In some apps, the client may be the signing authority (e.g. it owns the resource it's accessing).
In that case, the client can possess the JWK keypair and do its own signing.
reactordev · 3h ago
Some engineers forgot the secret/salt part of generating the jwt. Sometimes you can just pack some claims in there and encode it and it works!!
marifjeren · 3h ago
> 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.
None of this "BS" actually goes away with self-signed JWTs, right? Just replace mentions of "API Key" with public/private key and it's otherwise a similar process I think.
danscan · 2h ago
The things that change are:
1. With self-signed JWTs, you could start consuming APIs with free tiers immediately, without first visiting a site and signing up. (I could see this pattern getting traction as it helps remove friction, especially if you want to be able to ask an LLM to use some API).
2. Compare this scheme to something like the Firebase SDK, where there's a separate server-side "admin" sdk. With self-signed JWTs, you just move privileged op invocations to claims – consuming the API is identical whether from the client or server.
3. The authority model is flexible. As long as the logical owner of the resource being accessed is the one signing JWTs, you're good. A database service I'm working on embeds playgrounds into the docs site that use client-generated JWKs to access client-owned DB instances.
simsla · 2h ago
The problem I see with (1) is that it becomes a little bit too easy to regenerate public keys and circumvent free tier metering.
actinium226 · 2h ago
I guess that's easily addressed by requiring an account and a public key to access the free tier. Still better than having to get yet another API key.
danscan · 2h ago
For sure. Would likely need to be combined with another mechanism like IP rate limits
hirsin · 58m ago
I assure you it's far too easy to get as many ip addresses as you want if your interest is in avoiding rate limits.
danscan · 32m ago
Valid
nabwodahs · 3h ago
That site is blocked by Fortinet as "pornography."
snickerdoodle12 · 6m ago
Did you contact Fortinet since you're the one that apparently utilizes them?
danscan · 3h ago
Bummer. Not sure what I can do about that, but I assure you it is not pornography!
ghurtado · 2h ago
Sounds like someone must have gotten their "graphies" mixed up
rvz · 3h ago
This article uses "ES256" for the alg, GitHub uses "RS256" as their alg and a very deranged few use "none".
The point here is this article is giving the developer lots of rope to hang themselves with the JOSE standard on JWT/K/S and it is a sure way to implement it incorrectly and have lots of security issues.
PASETO is a much better alternative to work with: https://paseto.io with none of the downsides of the JOSE standard.
jillesvangurp · 2h ago
Yes you can create unsigned JWTs. Don't do that and don't accept any such tokens as valid (which would be the even bigger facepalm worthy mistake).
Just do it right (and at this point it is widely documented what the pitfalls are here), comply with the widely used and commonly supported standards, and follow the principle of the least amount of surprise. Which is kind of important in a world where things need to be cross integrated with each other and where JWTs, JOSE, and associated standards like OpenID connect are basically used by world+dog in a way that is perfectly secure and 100% free of these issues.
Honestly, it's not that hard.
The paradox with Paseto is that if you are smart enough to know what problem it fixes, you shouldn't be having that problem and also be smart enough to know that using "none" as an algorithm is a spectacularly bad idea. You shouldn't need Paseto to fix it if you somehow did anyway. And of course you shouldn't be dealing with the security layer in your product at all if that is at all confusing to you.
danscan · 3h ago
Haven't heard of PASETO, but I'll check it out. I'd say JOSE is an implementation detail of what I'm advocating for, so very open to alternatives.
When you "register" the public key with whatever the relying party is, you're also likely going to bind it to some form of identity, so you can't leak this private key to others, either. (And I'm curious, of course, how the relying party comes to trust the public key. That call would seem to require its own form of auth, though we can punt that same as it would be punted for an API key you might download.)
and it’s easy to do keypair generation in the browser using subtle crypto. That API doesn’t provide jwk generation, but seems like it would be relatively easy to do even without the jose module. And the browser cab “download” (really just save) the keypair using the Blob API. Keys need not leave the browser.
An api developer portal could just offer - generate a new keypair? - upload your existing public key?
…As a choice. Either way the public key gets registered for your account.
The end. Easy.
https://docs.github.com/en/apps/creating-github-apps/authent...
The JWT website is also super useful https://www.jwt.io/
(Maybe my confusion here is that these JWTs are being described as self-signed, as if there’s a JWK PKI cabal out there, like the bad old days of the Web PKI. There isn’t one that I know of!)
[Ed: allegations that the following is inaccurate! Probably checks out? Yes I meant the browser not the domain bound part, that seems solid.] Pity that Passkeys are so constrained in practice by browsers, that using them pretty much requires you trust the cloud providers absolutely with all your critical keys.
There's a proposal for cross-domain usage via Related Origins, but that scheme depends on the authority of the relying party, meaning you can't say "I'd like to be represented by the same keypair across this set of unrelated domains"
> Pity that Passkeys are so constrained in practice by browsers, that using them pretty much requires you trust the cloud providers absolutely with all your critical keys.
Passkeys are not constrained so you have to trust cloud providers or anyone else with all your critical keys. The key is resident in whatever software or hardware you want to use, and anyone can create passkey software or hardware that will work with Chrome etc. I'm talking about (and I'm pretty sure the OP was referring to) the other side of WebAuthn: where the credentials surfaced to JavaScript via WebAuthn actually come from and how the browser relays requests that a challenge is signed.
I wish there were something built into browsers that offered a scheme where your pubkey = your identity, but in short there are a lot of issues with that
But this scheme is flexible. You could also have the client send "requested" claims for the server to consider adding if allowed when getting a JWT.
You could also reverse-proxy client requests through your server, adding any claims the server allows.
In that case, the client can possess the JWK keypair and do its own signing.
None of this "BS" actually goes away with self-signed JWTs, right? Just replace mentions of "API Key" with public/private key and it's otherwise a similar process I think.
1. With self-signed JWTs, you could start consuming APIs with free tiers immediately, without first visiting a site and signing up. (I could see this pattern getting traction as it helps remove friction, especially if you want to be able to ask an LLM to use some API).
2. Compare this scheme to something like the Firebase SDK, where there's a separate server-side "admin" sdk. With self-signed JWTs, you just move privileged op invocations to claims – consuming the API is identical whether from the client or server.
3. The authority model is flexible. As long as the logical owner of the resource being accessed is the one signing JWTs, you're good. A database service I'm working on embeds playgrounds into the docs site that use client-generated JWKs to access client-owned DB instances.
The point here is this article is giving the developer lots of rope to hang themselves with the JOSE standard on JWT/K/S and it is a sure way to implement it incorrectly and have lots of security issues.
PASETO is a much better alternative to work with: https://paseto.io with none of the downsides of the JOSE standard.
Just do it right (and at this point it is widely documented what the pitfalls are here), comply with the widely used and commonly supported standards, and follow the principle of the least amount of surprise. Which is kind of important in a world where things need to be cross integrated with each other and where JWTs, JOSE, and associated standards like OpenID connect are basically used by world+dog in a way that is perfectly secure and 100% free of these issues.
Honestly, it's not that hard.
The paradox with Paseto is that if you are smart enough to know what problem it fixes, you shouldn't be having that problem and also be smart enough to know that using "none" as an algorithm is a spectacularly bad idea. You shouldn't need Paseto to fix it if you somehow did anyway. And of course you shouldn't be dealing with the security layer in your product at all if that is at all confusing to you.