fix: validate JWT audience and issuer claims

[alanzabihi]

What kind of change does this PR introduce?

Bug fix

What is the current behavior?

jwtVerify in verify-credentials.ts is called without audience or issuer options:

const { payload } = await jwtVerify(credentials.token, jwkSet)

Any JWT signed by a key in the project's JWKS is accepted, regardless of who issued it or who it was intended for. In setups where multiple services share signing keys (common in self-hosted Supabase), a token minted by Service A is accepted by Service B as valid user auth.

What is the new behavior?

Two new optional fields on SupabaseEnv: audience and issuer. When set, they're forwarded to jwtVerify's options. Tokens that don't match are rejected with InvalidCredentialsError.

New environment variables: SUPABASE_JWT_AUDIENCE and SUPABASE_JWT_ISSUER. Both are optional. Existing behavior is unchanged when they aren't set.

Files changed:

• src/types.ts -- add audience? and issuer? to SupabaseEnv
• src/core/resolve-env.ts -- read the new env vars
• src/core/verify-credentials.ts -- pass them to jwtVerify
• docs/security.md -- document the new options and why they matter
• docs/environment-variables.md -- list the new vars

Tests:

The actual logic this PR adds is: "if the env field is set, pass it to jose." The claim validation itself happens inside jose. Every existing user mode test already calls makeEnv() without audience or issuer, so the backward-compatible path is implicitly covered.

The one test worth adding is a resolveEnv wiring test: does it correctly read SUPABASE_JWT_AUDIENCE and SUPABASE_JWT_ISSUER from the environment and surface them on SupabaseEnv? Happy to add that if you'd like.

[kallebysantos]

Hey mate thx for it 💚
we're still deciding the impacts of adding it... SUPABASE_* prefix is reserved and it would impact on exposing these envs from platform default environment, what I'm not sure if would be a breaking change...

Meantime could you fix/rebase the merging conflicts?

[alanzabihi]

Rebased on latest main and resolved the conflicts.

[kallebysantos]

Better keep it as non-default Supabase available.
Users need to manually supply it from env property when working in a Supabase Environment.

cc @tomaspozo, This envs are blockers if you consider merging it, like we discussed before I don't plan to expose it at Platform / any other Supabase environment.

[kallebysantos]

It should be fine to merge without coupling this envs, so the feature JWT audience will be optional and requires manual setup.

@alanzabihi, are u okay with manual setup using env property? like I described in the comment above, the requirement of theses envs are blocking this PR.

[mandarini]

@alanzabihi Agree with @kallebysantos. Audience and issuer should stay config-only, not auto-read from SUPABASE_JWT_AUDIENCE / SUPABASE_JWT_ISSUER. Those names sit next to Platform-provisioned vars. If Platform ever sets one, verification behavior would change with no code change on the user's end.

The overrides path in resolve-env.ts already covers this. Can you drop the getEnvVar fallbacks for both vars (and the matching wiring test), and update the docs so audience/issuer are only set through the env override?

Rest of the PR looks good. Can you also please rebase again, this shows conflicts.