Nice move by Supabase switching to asymmetric JWTs, eliminating the need to always call getUser() for verification should noticeably reduce latency at the edge; curious if anyone’s benchmarked how much faster auth.getClaims() actually is in practice compared to getUser()?
focom•6mo ago
You will save network latency every time, so probably 100-200ms for every call
xytofs•6mo ago
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.
sophiabannet1•6mo ago
focom•6mo ago
xytofs•6mo ago
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.