supabase / supabase-flutter / 38226711363

92%

push

github

fix(auth): expire the cached JWKS in getClaims after its TTL (#1946)

### Problem

`getClaims()` passes its own in-memory JWKS cache to `_fetchJwk` as the
"supplied" key set, and that lookup returns before the TTL check runs.
Once a `kid` is in the cache it is served for the lifetime of the
client: `AuthConstants.jwksTtl` (10 minutes) is never consulted for a
key that is already cached, so a signing key that has been rotated out
and revoked keeps verifying tokens locally until the process restarts or
a token with an unknown `kid` happens to replace the cache.

auth-js only short-circuits on the caller-supplied `options.jwks`, which
this SDK does not have, and refreshes its cache after 10 minutes. The
capability spec for `auth.session.get_claims` states the JWK Set is
cached in the client for ten minutes, matching the `Cache-Control:
public, max-age=600` the endpoint serves.

This came in with #1300, which replaced the `_jwks!` force-unwrap at the
call site with `_jwks ?? JWKSet(keys: [])`, so the cache started
arriving through the supplied-set parameter.

### Fix

`_fetchJwk` now reads the cache through the TTL check only, and the
supplied-set parameter is gone since nothing else ever passed one. An
`@internal`, `@visibleForTesting` `jwksCachedAt` accessor lets the tests
age the cache directly, so no new dependency is needed.

No public API change.

### Tests

Two tests in `get_claims_mock_test.dart`:

- within the TTL a second `getClaims()` reuses the cache: one JWKS
request, no `/user` call.
- after the TTL the JWKS is refetched; the rotated set no longer carries
the token's `kid`, so verification falls back to `/user`, which answers
401 and surfaces as `AuthApiException`. On `main` this test fails: the
stale key verifies the token locally, with no second JWKS request and no
`/user` call.

Ran the 481 `supabase_auth` unit tests that do not need a server, `dart
analyze --fatal-infos` and `dart format --set-exit-if-changed`. The
integration suite was ... (continued)

6 of 6 new or added lines in 1 file covered. (100.0%)

9501 of 10380 relevant lines covered (91.53%)

5.19 hits per line