S
Supabase•3d ago
Colin Emonds

Cannot access new service role API key from Edge Function runtime

Hi, so, apparently Supabase has deprecated their bad authentication scheme in favor of an even more broken one, while addressing none of the issues with the old one, and not even bumping the major version number to announce the breaking change. Cool - that's the quality I'm used to at this point. One particular pain point with the newly introduced API keys, though, is that I have a bunch of Edge Functions which I only want to be accessible to users that know the service role key. The reasoning is that these Edge Functions perform system maintenance or data import tasks that regular users should not be able to control, and they only get called via an admin curling them. My previous solution essentially was this: 
Deno.serve(async (req) => {
  if (
    req.headers.get('authorization') !==
    `Bearer ${Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')}`
  ) {
    return new Response('Unauthorized', { status: 401 });
  }
Deno.serve(async (req) => {
  if (
    req.headers.get('authorization') !==
    `Bearer ${Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')}`
  ) {
    return new Response('Unauthorized', { status: 401 });
  }
This worked perfectly fine for me. But with the new system, I am not sure what I'm supposed to do here. 1. I'm not supposed to use the JWT-based service role anymore. In local development, this already doesn't work, as the CLI tools no longer show it. (I could probably hack around that, but that wouldn't be future-proof.) 2. I can't use the new API key, as I am not sure how to access it. It doesn't appear to be documented anywhere how that key could be obtained, and in any case, it's not in Deno.env. So I guess I create a vault secret system_administration_api_key and then use that for my edge functions? I'm mostly just venting here, I suppose.
4 Replies
Colin Emonds
Colin EmondsOP•3d ago
This is more annoying for people who actually relied on the key to authenticate their supabasejs client as service_role from their Edge Function. I don't even know what the proposed migration plan is for these applications. It's still massively annoying in any case, because why does the verify_jwt option in config.toml still exist if we're no longer verifying any JWTs? Also, apparently verify_jwt is just ignored now? Even when I set it to false, in local development, Edge Functions will still refuse to be called because Error: Missing authorization header. That completely breaks all webhooks I have.
silentworks
silentworks•3d ago
This doesn't change at all, you would still use the same SUPABASE_SERVICE_ROLE_KEY environment variable and it will work. Locally it seems to have some confusion as the edge functions are still using the old key while supabase status is showing the new key. This seems more like a CLI bug. I do agree with you that communication around this change were poor and there are still some use-cases that are poorly documented like the verify_jwt stuff. I hope Supabase fix these before completely removing the old keys.
Colin Emonds
Colin EmondsOP•3d ago
You're right, if I start the local functions server with --no-verify-jwt, it will still do the right thing. It's just the config that doesn't get picked up. It's probably a CLI bug then. I assume SUPABASE_SERVICE_ROLE_KEY will then contain a JWT minted with the new asymmetric JWT root key? I was under the impression that going forward, service role authorization would only be possible via API key, not JWT. If that's not the case, that's great. Thank you for the response.
silentworks
silentworks•3d ago
On the hosted version SUPABASE_SERVICE_ROLE_KEY is the actual new secret key and not the old service role key. I've tested this myself.

Did you find this page helpful?