[marifjeren]

> 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]

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]

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]

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.

[llbbdd]

Same difference to most people and dead on arrival.

[actinium226]

For web dev, where, sadly, it's the norm to have about 13 different services for a website, it would greatly simplify having to herd 13 API keys around

[remram]

Yeah that's not happening. In fact most services with free tiers still ask for a credit card number, and if not still ask for a lot of information. It is a marketing scheme after all.

[danscan]

For sure. Would likely need to be combined with another mechanism like IP rate limits

[hirsin]

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]

Valid

[kassner]

> you could start consuming APIs with free tiers immediately, without first visiting a site and signing up

I’m yet to see a website that provides an API and doesn’t have a ToS that you have to agree to. Unless you control both parties, or you expose your service only to pre-vetted customers, there is no legal department that is going to allow this.

[chii]

you put as part of the claims in the jwt that you agree to the TOS (may be something like { ... TOS:www.service.com/tos.txt, TOSAgreed:true ... }), which you sign. Then this is an explicit agreement from you as a client.

[weitendorf]

Correct, because to fully leverage self-signed (or distributed or decentralized or whatever) JWTs you have to handle identity in a different way than typical consumer auth works on the Internet today.

Right now, user identity is ~based on email, which is in practice very often delegated to a third party like gmail, because most people do not host their own email. So identity = [e-mail]. To properly validate self-signed JWTs you'd have to instead either host or delegate distinct JWKS endpoints for each identity. Then identity = https://bobsjwkshost.fun/foo. You still have to create and verify an account through a third party, otherwise, your self-signed JWT is just as credible as a self-signed TLS cert.

In both cases the underlying identity model is actually based on DNS, IP, and internet domains - whoever controls those for your email/JWKS controls what gets served by those addresses. So to fully self-host email or JWKS you need to own your own domain and point email/http to IP addresses or other domains. And you need to have something servery running under that IP to handle email/https. That's a big hurdle to setup as is, but even so, all this really does is kick up identity delegation one more notch to the IANA, who decide who owns what domains and IP addresses, by delegating them to registrars and regional Internet registries, with further delegation to AS to actually dole out IP addresses to proles.

I recently started the process of becoming a registrar and securing my own IP addresses and realized THERE ARE STILL MORE LAYERS. Now I have to pay a whole bunch of money and fill out paperwork to prove my business' legal legitimacy and get the stupid magic Internet numbers we call IP addresses. Which then relies on my country's legal and financial systems... And by the way, this part is just completely infeasible for a regular user to actually follow through with (costs are high five digits USD or low six digits USD, IIRC, takes a ton of time).

Because the IANA is a stodgy bureaucratic Important Institution That I Cannot Change, IMO the best way to implement self-hosted auth is by making it as cheap and simple as possible to register a domain and serve email/jwks on it. If we pay them even more money they'll give us a TLD which we should be able to make available for $0.20 (IANA base registration fee because of course) or just eat the cost and make it free pending some other verification process. And then we can set up a portable "serverless" JWKS/SMTP handling tool that people can run.

I've been thinking about this self-hosted identity/auth problem quite a lot and I think there's no ideal solution. If you're fully decentralized and trustless you're probably using "blockchain" and won't have enough throughput, will lock people out of everything online if they lose a key, and will still probably make consumers pay for it to stave off sybil attacks. Also, to use the internet you have to trust the IANA anyway. So just upgrade every authenticated user into their own identity provider and make it extremely cheap and easy to operate, and at long last you can get those precious seconds back by signing up for Internet services with a JWKS path instead of an email address.

[marifjeren]

> In both cases the underlying identity model is actually based on DNS, IP, and internet domains - whoever controls those for your email/JWKS controls

Hmm I wonder if you are thinking that the JSON webkeys of the user need to be hosted publicly. I don't think they technically do. It's a common convention to do so (especially at some well-known URL).

But the user actually could instead send their public key on each and every JWT-bearing request they send, and as long as that public key is both (1) pre-registered with the API owner and tied to some identity the API recognizes as some authorized user and (2) can successfully be used to validate the signature, it should work just fine.

[weitendorf]

How do you pre-register them then? What prevents someone else from trying to register or push my JWKS to the API owner? If you are in an open security context (eg the Internet) you would then still need another way to handle Identity

[marifjeren]

> How do you pre-register them then?

Exactly my complaint. You still have to go into some web portal and install your public key, I guess.

> What prevents someone else from trying to register or push my JWKS to the API owner?

Well for one thing they wouldn't have access to your public key since you won't be hosting them publicly somewhere. But for another thing it will be useless to them unless they have access to your private key