[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.

[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

[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.