feat(functions): add hybrid JWT verification to TS edge runtime#5560
feat(functions): add hybrid JWT verification to TS edge runtime#5560avallete wants to merge 10 commits into
Conversation
Port the asymmetric JWT support from the Go CLI (#4721, #4985) to the TypeScript edge runtime. The runtime now verifies ES256/RS256 tokens against a JWKS, falling back to the legacy symmetric secret for HS256, and exposes the JWKS to user workers via SUPABASE_JWKS. https://claude.ai/code/session_01Vn3KQfhzbP2X3QNqs36sKR
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fc5d8d95bc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Add an e2e case that exercises the real Deno edge runtime: missing credentials and forged HS256 tokens are rejected, while a validly-signed HS256 token and the apikey -> minted sb-api-key compatibility path are accepted. https://claude.ai/code/session_01Vn3KQfhzbP2X3QNqs36sKR
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b7fdcbd4ca
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Supabase CLI previewnpx --yes https://pkg.pr.new/supabase@5560Preview package for commit |
- Type the lazy jose import via a string specifier + hand-written interface so every workspace that compiles the text-embedded runtime file (including apps/cli) type-checks without resolving the Deno-only `jsr:` module. - Fall back to the remote well-known JWKS when the injected local JWKS has no key matching an asymmetric token, instead of failing closed. - Re-enable JWT verification explicitly in the e2e test; reloadFunctions() with no options preserves the original noVerifyJwt config. https://claude.ai/code/session_01Vn3KQfhzbP2X3QNqs36sKR
The lazy dynamic import used a non-literal specifier, which the edge runtime cannot statically discover and pre-load, so jose failed to import at runtime and JWT verification threw (HTTP 500 instead of 401). Inject a static `import * as jose from "jsr:@panva/jose@6"` when materializing the runtime script, and consume it as an ambient `jose` global in the source. This matches the Go template's runtime import while keeping the `jsr:` specifier out of the bun-typed source entirely (no .d.ts, triple-slash, or knip ignore). https://claude.ai/code/session_01Vn3KQfhzbP2X3QNqs36sKR
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3ab48f16e0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| publishableKey: stackConfig.publishableKey, | ||
| secretKey: stackConfig.secretKey, | ||
| jwtSecret: stackConfig.jwtSecret, | ||
| jwks: generateJwks(stackConfig.jwtSecret), |
There was a problem hiding this comment.
For projects that configure asymmetric auth inputs such as auth.signing_keys_path or auth.third_party (both are loaded by @supabase/config), this writes a JWKS derived only from the legacy jwtSecret. As a result, ES256/RS256 tokens signed by the configured local signing key or third-party provider are absent from SUPABASE_JWKS; the fallback only asks the local GoTrue JWKS endpoint, not the configured provider/file, so Edge Functions reject tokens that the hybrid verifier is meant to support. Resolve the JWKS from the loaded project auth config rather than always calling generateJwks(stackConfig.jwtSecret).
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Leaving this one open as a known limitation rather than fixing it in this PR, because the local stack doesn't yet support asymmetric signing locally:
- The local auth service is configured with the symmetric secret only —
StackBuilderpassesversion,port,siteUrl,jwtExpiry, andexternalUrlto the auth service, but notauth.signing_keys_pathorauth.third_party. So local GoTrue mints HS256 tokens signed withjwtSecret, andgenerateJwks(stackConfig.jwtSecret)is the correct local key set for them. - Since no asymmetric key is wired into the local issuer, putting
signing_keys_path/third_partykeys intoSUPABASE_JWKSwouldn't match any locally-minted token today. - Externally-minted asymmetric tokens are still handled by the remote
/auth/v1/.well-known/jwks.jsonfallback for keys the local auth service is aware of.
Properly sourcing SUPABASE_JWKS from the configured signing keys / third-party providers requires first plumbing those into the local auth service so it actually signs with them — that's a larger, separate change. Happy to file a follow-up issue if you'd like to track it.
Generated by Claude Code
Replace the jose/jsr dependency with self-contained WebCrypto verification: HS256 via crypto.subtle HMAC (restoring the proven legacy path) and ES256/RS256 by importing JWK public keys from the local JWKS, falling back to the auth service's well-known endpoint. The remote JWKS is cached per URL. This removes the runtime failure where a valid HS256 token was rejected, and avoids resolving a Deno-only jsr module at edge-runtime startup (so stacks with no functions, noVerifyJwt, or no network still boot). https://claude.ai/code/session_01Vn3KQfhzbP2X3QNqs36sKR
avallete
left a comment
avallete
left a comment
There was a problem hiding this comment.
Reviewed the hybrid JWT verification port. The verifier architecture is sound: hand-rolling on WebCrypto is the right call for an injected script with no bundled deps, algorithm confusion is handled correctly (alg allow-list, HS256 never touches JWKS keys, asymmetric candidates filtered by kty), and the failed-fetch cache eviction is done properly.
Two things I'd address before merge, detailed inline:
- Missing
exp/nbfvalidation — expired tokens with valid signatures are accepted, diverging from the Go/Docker runtime this ports (jose/golang-jwt validate expiry by default). fetchRemoteJwkscan permanently cache an empty key set when the auth service responds non-2xx with a JSON body (nores.okcheck).
Also inline: the local-JWKS branch is currently dead code for asymmetric tokens (the injected JWKS is oct-only), the ES256/RS256 paths have no test coverage (suggest unit tests on exported helpers rather than more e2e), and the new e2e test flips noVerifyJwt on the shared stack without restoring it.
Generated by Claude Code
- Reject expired (exp) / not-yet-valid (nbf) tokens with clock skew, matching the Go/Docker runtime behavior - Skip caching empty/failed JWKS responses (res.ok check + empty-set eviction) - Match keyless JWKS entries so single-key sets that omit kid still verify - Drop per-candidate verification log noise - Export verifyHybridJwt/verifyWithJwks/areClaimsValid and add unit coverage for the ES256/RS256, kid-filtering, remote-fallback, and claim paths - Restore noVerifyJwt on the shared e2e stack after the hybrid test
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c83bda6b6c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
![depthfirst-app[bot]](https://avatars.githubusercontent.com/in/1021002?s=60&v=4){kind=small}
- Add a 5-minute TTL to the remote JWKS cache so rotated/revoked signing keys stop verifying against a stale cached set without a runtime restart - Reject non-object JWT payloads (e.g. JSON null) so they fail the auth gate with a 401 instead of throwing into a 500 - Reject non-numeric exp/nbf claims rather than silently skipping them - Cover the TTL refetch, null payload, and malformed-claim cases in unit tests
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 80e5620b8a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
A JWT claims set must be a JSON object; an array payload (e.g. []) was treated as an object and skipped the temporal-claim checks.
…WKS gap The CLI-injected JWKS is symmetric-only (oct), so it could never verify an ES256/RS256 token; remove the dead local-JWKS-first branch and verify asymmetric tokens against the auth service's well-known JWKS only. Keep the oct JWKS in SUPABASE_JWKS (correct for the default local HS256 issuer, matching the Go CLI's ResolveJWKS fallback) and add a TODO to also resolve signing_keys_path / third_party keys. Rework the asymmetric unit tests to exercise the remote path.
jgoux
left a comment
jgoux
left a comment
There was a problem hiding this comment.
Thanks for the solid cleanup through the review rounds. I verified the final head locally:
pnpm --filter @supabase/stack test:corepnpm --filter @supabase/stack check:allpnpm --filter @supabase/stack exec bun --bun vitest run --project e2e tests/createStack.e2e.test.ts
I found one remaining correctness gap that I think should be addressed before merging: the PR claims hybrid/asymmetric support for the TS edge runtime, but the TS stack still only resolves an HS256 secret-derived JWKS and does not wire auth.signing_keys_path / auth.third_party into either the auth service or the function SUPABASE_JWKS env. That means the new verifier works for mocked remote JWKS and the legacy HS256 path, but still does not provide the Go-side parity for configured local asymmetric keys/third-party providers.
Two lower-severity follow-ups I noticed:
- The added e2e is valuable, but it only exercises HS256 plus the
apikeycompatibility path; ES256/RS256 remain unit-only with mockedfetch. A runtime-level asymmetric smoke test would make this much stronger. - The shared e2e stack should restore
noVerifyJwtin afinally, so a failed assertion does not leak JWT enforcement into later tests.
| expect(await res.text()).toBe("later"); | ||
| }); | ||
|
|
||
| test("enforces hybrid JWT verification on Edge Functions", { timeout: 20_000 }, async () => { |
There was a problem hiding this comment.
This e2e name says “hybrid JWT verification,” but the scenario only covers missing credentials, forged HS256, valid HS256, and the apikey compatibility path. The ES256/RS256 branch is only covered in unit tests with a mocked JWKS fetch, so we still do not have runtime proof that the actual edge-runtime + gateway + auth JWKS path works. Please add an asymmetric runtime smoke test or rename/scope this e2e to the HS256 legacy path it actually exercises.
| writeFunction(projectDir, "secure", "secure"); | ||
| // The stack was created with noVerifyJwt; re-enable verification explicitly | ||
| // (reloadFunctions() with no opts would keep the original config). | ||
| await stack.reloadFunctions({ noVerifyJwt: false }); |
There was a problem hiding this comment.
After this flips the shared stack to noVerifyJwt: false, any assertion failure before the restore at the end leaves JWT verification enabled for the remaining tests in this file. Please wrap the assertions in try/finally and restore noVerifyJwt: true in the finally block so later tests do not inherit hidden state after a failure.
|
After discussion with @kallebysantos I'll turn this back into a draft and let him take over. Implementation of the auth for edge functions might see some changes soon. |
Pull request was converted to draft
4 participants
Port the asymmetric JWT support from the Go CLI (#4721, #4985) to
the TypeScript edge runtime. The runtime now verifies ES256/RS256 tokens
against a JWKS, falling back to the legacy symmetric secret for HS256, and
exposes the JWKS to user workers via
SUPABASE_JWKS.How this differs from the Go implementation
This is not a 1:1 port. The Go CLI verifies tokens with a JWT library,
but the edge runtime's auth gate lives in the main worker script that the CLI
injects as source into the runtime — it can't rely on bundled npm
dependencies. So verification here is implemented by hand directly on
WebCrypto (
crypto.subtle), with nojose/JWT library:HS256→crypto.subtle.verifywith the raw symmetric secret (legacy path).ES256/RS256→crypto.subtle.importKey("jwk", …)+verify, withper-algorithm import/verify params (
ECDSA/P-256,RSASSA-PKCS1-v1_5).Tokens are also checked for
exp/nbf(with a small clock-skew window) beforethe signature, matching the Go/Docker runtime, which reject expired tokens by
default.
JWKS resolution
Key resolution is hybrid and ordered: the JWKS injected by the CLI
(
config.jwks) is checked first, then the auth service's/auth/v1/.well-known/jwks.jsonendpoint. Candidate keys are filtered byktyand
kid(keys without akidstay eligible so single-key sets that omit itstill verify). Remote JWKS responses are cached per-URL; failed and empty
responses are not cached.
Note that the CLI-injected
config.jwksis currently symmetric-only (anoctkey derived fromjwtSecret), so it never matches an ES256/RS256 tokentoday — that local check is future-proofing for when the local stack grows
asymmetric signing keys, and real asymmetric verification currently resolves
through the well-known endpoint. Sourcing
SUPABASE_JWKSfrom configuredsigning keys / third-party providers is tracked as a follow-up (it first
requires wiring asymmetric signing into the local auth service).
SUPABASE_JWKSis also forwarded into the user worker environment so functioncode can read the same key set the gate uses.
https://claude.ai/code/session_01Vn3KQfhzbP2X3QNqs36sKR