feat: add hybrid jwt verification

[kallebysantos]

What kind of change does this PR introduce?

Bug fix, feature

What is the current behavior?

Since API keys did change, users can't call functions without manually disabling verify_jwt.

What is the new behavior?

JWKs are now default exposed #4688, so It allows to verify both new asymmetric tokens as well legacy ones.

This way it applies a temporary fix while migrating API keys.

• closes JWT key verification broken (Edge Runtime 1.7.0+) for self-hosted deployments edge-runtime#654
• solves ES256 JWT verification fails in Edge Functions after CLI upgrade to 2.72.6 supabase#41929

[coveralls]

Pull Request Test Coverage Report for Build 20992742862

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 7 unchanged lines in 2 files lost coverage.
• Overall coverage remained the same at 56.148%

---

Files with Coverage Reduction	New Missed Lines	%
internal/storage/rm/rm.go	2	80.61%
internal/gen/keys/keys.go	5	12.9%

Totals
Change from base Build 20983346857:	0.0%
Covered Lines:	6850
Relevant Lines:	12200

---

💛 - Coveralls

[joelpramos]

@kallebysantos Deno.env.get doesn't seem to have access to "SUPABASE_INTERNAL_*" for me. Is there any property that needs enablement?

const JWT_SECRET = Deno.env.get('SUPABASE_INTERNAL_JWT_SECRET')!;
const HOST_PORT = Deno.env.get('SUPABASE_INTERNAL_HOST_PORT')!;
const DEBUG = Deno.env.get('SUPABASE_INTERNAL_DEBUG') === 'true';
const FUNCTIONS_CONFIG_STRING = Deno.env.get(
  'SUPABASE_INTERNAL_FUNCTIONS_CONFIG'
)!;

async function verifyLegacyJWT(
  jwt: string
): Promise<JWTVerifyResult<JWTPayload> | undefined> {
  // const JWT_SECRET = Deno.env.get('SUPABASE_INTERNAL_JWT_SECRET')!;
  logger.debug('JWT secret: ' + JWT_SECRET);
  logger.debug('Host port: ' + HOST_PORT);
  logger.debug('Debug: ' + DEBUG);
  logger.debug('Functions config string: ' + FUNCTIONS_CONFIG_STRING);
  const encoder = new TextEncoder();
  const secretKey = encoder.encode(JWT_SECRET);
  try {
    return await jwtVerify(jwt, secretKey);
  } catch (e) {
    logger.error('Symmetric Legacy JWT verification error', e);
    return undefined;
  }
}

[kallebysantos]

Hi @joelpramos 💚
Could you give me more context about your version? Are you calling it inside an edge function or just trying my fork?

[joelpramos]

hi @kallebysantos:

• Supabase version 2.75.0
• Local (self hosted)
• Just trying to replicate your middleware change, not using your fork
• Getting the var from within a Supabase edge function (my middleware, trying to replicate what you have here as I have this problem locally)
• I can see the vars injected in the container itself and confirmed by opening the shell and printing it

[kallebysantos]

Hey @joelpramos 💚
The SUPABASE_INTERNAL_* are only available inside CLI context as internal envs for the docker local-dev stack — So it only works in this fork / supabase start command (only for internal main.ts scope)

Since you're using self-hosted, the main/index.ts template already implements the legacy verification and the env is named as JWT_SECRET.

I'm not really sure, but new JWK are not available for self-hosting yet, so you "can't" replicate this hybrid replication — At least without extra manual steps.

cc @aantti can give you more details about Self-Host situation of new Asymmetric Keys.

[aantti]

can give you more details about Self-Host situation of new Asymmetric Keys

It's WIP :) Hoping to add it soon.

[joelpramos]

@aantti @kallebysantos at least locally the new solution works totally fine for users but not for service_user (e.g., functions triggered from Cron). I am also having some issues in the deployed instance with functions triggered from cron jobs but haven't triaged yet the root cause and missing some logs.

fwiw other than the fact the variable wasn't available, this hybrid solution you posted @kallebysantos works for me i.e. seems like the service_role from the cron user is using the old auth method. Is that something on both your radars?

[kallebysantos]

Hey @joelpramos

service_role...is using the old auth method

Yes, ANON_KEY and SERVICE_ROLE uses old auth (symmetric JWT) which can be verified from *JWT_SECRET

...fine for users but not for the service_role...

I don't think so, user's tokens is now being issued as new JWT (Asymmetric JWK) and the purpose of this PR is to handle both kinds of tokens, using legacy as fallback.
So it should work for any valid token... but I can do more testing to make sure if cron requests is working fine.