getClaims() uses a multi-level cache + WebCrypto API to verify JWTs signed with an asymmetric key locally.
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.
> how are your security teams ok with exposing your PG server to the internet, relying mainly on RLS? And RLS isn't turned on by default, so full tables are exposed to the public internet by default, behind a rather nice REST API.
Tooling is improving constantly and security really is at the top of mind for us. We've got some cool announcements this week that will keep reminding you if you're doing something sketchy!
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.