[HN Gopher] Self-Signed JWTs
___________________________________________________________________
Self-Signed JWTs
Author : danscan
Score : 55 points
Date : 2025-08-01 18:27 UTC (4 hours ago)
(HTM) web link (www.selfref.com)
(TXT) w3m dump (www.selfref.com)
| beckthompson wrote:
| Github has a cool little article on making JWTs for their API.
| Very useful!
|
| https://docs.github.com/en/apps/creating-github-apps/authent...
|
| The JWT website is also super useful https://www.jwt.io/
| rvz wrote:
| 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.
| danscan wrote:
| 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.
| jillesvangurp wrote:
| 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.
| JohnMakin wrote:
| 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
| reactordev wrote:
| 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!!
| danscan wrote:
| (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 wrote:
| 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.
| nabwodahs wrote:
| That site is blocked by Fortinet as "pornography."
| danscan wrote:
| Bummer. Not sure what I can do about that, but I assure you it
| is not pornography!
| ghurtado wrote:
| Sounds like someone must have gotten their "graphies" mixed
| up
| marifjeren wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| For sure. Would likely need to be combined with another
| mechanism like IP rate limits
| clysm wrote:
| You still haven't addressed the flow when someone needs to
| associate one of these keys with a known account in a secure
| manner. Or deal with rotation / revocation.
| woodruffw wrote:
| 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 wrote:
| 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
| actinium226 wrote:
| 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.
| esseph wrote:
| This is similar to ssh key auth. (Pubkey, privkey)
| PantaloonFlames wrote:
| 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.
| jauntywundrkind wrote:
| The model here feels not entirely dissimilar to Passkeys? Both
| are user provided auth tokens??
|
| 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.
___________________________________________________________________
(page generated 2025-08-01 23:00 UTC)