Asymmetric JWTs with Supabase Auth

Cache is this:

1. Origin server is always Supabase Auth, which like all auth servers is difficult to distribute globally. It serves /auth/v1/.well-known/jwks.json with a 10 minute cache-control header.

2. Supabase's Edge caches this response closest to where it was requested. Re-requesting within 10 minutes here can be as fast as 10ms but usually around 20ms. This latency comes from peering latency between whoever is hosting the server requesting the resource, and the edge.

3. This response is further cached in memory in the client library for 10 minutes.

Now when it's pulled from the memory cache, the latency is really the speed of the WebCrypto API which is super fast and done in microseconds (not milliseconds!).

Depending where you use getClaims(), the memory cache may not actually be used. For instance Vercel's Fluid compute has persistent RAM between requests so you're in for a super nice treat for most requests.

If not using Fluid compute, memory isn't shared between requests so only the Edge cache would apply. This means the values are cached close (but not inside) Vercel's network, so you'd see consistent 10-20ms (give or take, very approximate numbers) here.

Anyway, if 10-20ms is still not acceptable, you can pass an option to getClaims() with a static JSON Web Key Set configuration. No cache is used now and it all depends on the WebCrypto API -- so microseconds.

This isn't recommended (unless you absolutely know what you're doing) as key revocation will be difficult for you in the future. The client library does its best, but if the signing key has leaked you must manually revoke by updating your backends.