Third party auth not working with Storage

[martinbaste]

Describe the bug
I've searched issues, discussions and discord.

I'm trying to use a Cognito JWT with Supabase. I've followed the documentation to integrate with Cognito.

Fetching from Supabase database works fine using the JWT. But trying to get private files from Storage fails with the error 'invalid algorithm'.

I'm running it locally.

I've checked the source code and I wonder if there is a bug with the environment variables, I wanted to double check here if someone has successfully gotten it to work.
I suspect there is a mismatch between the environment variables that the supabase cli creates (see here, notice AUTH_JWT_ALGORITHM is also not set) and what Storage expects (see here)

I tested the JWT against the cloud Supabase Storage and it seems to work, so it looks like a bug in Supabase CLI.

To Reproduce
Configure Supabase to use Cognito for auth
config.toml

[auth.third_party.aws_cognito]
enabled = true
user_pool_id = "xxx"
user_pool_region = "xxx"

Send a POST request to sign an image with the JWT token in the Auth Bearer header:

http://127.0.0.1:54321/storage/v1/object/sign/bucket/image.jpeg

I get an invalid algorithm error

{"statusCode":"403","error":"Unauthorized","message":"invalid algorithm"}

From looking at the code (see links above), I think that the issue is caused by the Storage docker container not getting the right environment variables. I've tested this in the cloud version of Supabase and I suspect it works (I get a 404 because I haven't fixed the policies, but it goes past the JWT check).
Again, fetching data from the Supabase Database works with my JWT, so I know its valid.

Expected behavior
Once configuring Cognito as third party auth, I'd expect Storage to accept its JWT.

Screenshots
N/A

System information
No specific command fails but this is my system info

• Ticket ID: N/A
• Version of OS: Sonoma macOS 14.6
• Version of CLI: 2.20.5
• Version of Docker: 27.4.1, build b9d17ea
• Versions of services:

  
        SERVICE IMAGE      │      LOCAL       │ LINKED
  ─────────────────────────┼──────────────────┼─────────
    supabase/postgres      │ 15.8.1.060       │ -
    supabase/gotrue        │ v2.170.0         │ -
    postgrest/postgrest    │ v12.2.8          │ -
    supabase/realtime      │ v2.34.43         │ -
    supabase/storage-api   │ v1.19.3          │ -
    supabase/edge-runtime  │ v1.67.4          │ -
    supabase/studio        │ 20250317-6955350 │ -
    supabase/postgres-meta │ v0.87.1          │ -
    supabase/logflare      │ 1.12.0           │ -
    supabase/supavisor     │ 2.4.14           │ -

Additional context

[andymiller-og]

I am having a similar issue, which I had posted (along with another issue today) the following:

I'm setting up local development using supabase start and the recommended native Clerk third-party auth integration (not the deprecated JWT template).

Setup:

• Using useSupabaseClient with the accessToken function returning session.getToken() client-side.
• supabase/config.toml has the correct [auth.third_party.clerk] section with enabled = true and my Clerk dev domain correctly specified.
• .env.local points to the local Supabase URL/anon key from supabase start.
• RLS policies updated to use (select auth.jwt()->>'sub').

Problem:

• Clerk login/signup seems to work fine.
• However, when making authenticated requests to Supabase after login (specifically trying to upload to Storage), I consistently get a 403 Unauthorized error with the message invalid algorithm.
• This happens despite multiple restarts, supabase db reset, and verifying the config.toml.

Key Observation:

• When I run supabase start, the output still includes a line like JWT secret: super-secret-jwt-token-with-at-least-32-characters-long. This suggests the GoTrue container might not be correctly applying the [auth.third_party.clerk] settings from config.toml and is falling back to the default symmetric secret, causing the algorithm mismatch when it receives the RS256 token from Clerk.

Has anyone seen this behavior where the config.toml third-party settings don't seem to override the default JWT secret locally? Any pointers on how to ensure the local GoTrue container properly recognizes the Clerk domain for JWKS verification?

Thanks!

[AidanFogarty]

Also adding that I am seeing this issue on local development. I only see it when trying to do anything with storage, normal tables within the public schema seem to work correctly.

When tested with a live cloud version of supabase, it works correctly.

[andymiller-og]

Okay @AidanFogarty looks like I figured out a solution - if you go and install their latest pre-release it works again. I dont know if you need to install v2.20.12 but something somewhere between that and v2.20.5 solved this for me!

For Apple Silicon, here are the steps

brew uninstall supabase
curl -L -o supabase_darwin_amd64.tar.gz https://github.com/supabase/cli/releases/download/v2.20.12/supabase_darwin_amd64.tar.gz
tar -xzvf supabase_darwin_amd64.tar.gz
mv supabase /usr/local/bin/
supabase --version

[andymiller-og]

Okay @AidanFogarty looks like I figured out a solution - if you go and install their latest pre-release it works again. I dont know if you need to install v2.20.12 but something somewhere between that and v2.20.5 solved this for me!

For Apple Silicon, here are the steps

brew uninstall supabase
curl -L -o supabase_darwin_amd64.tar.gz https://github.com/supabase/cli/releases/download/v2.20.12/supabase_darwin_amd64.tar.gz
tar -xzvf supabase_darwin_amd64.tar.gz
mv supabase /usr/local/bin/
supabase --version

I am not sure this actually does fix it. The error popped back up.

[ShepSims]

We have started seeing this today as well, when uploading an image. The code has been in production unchanged for a few months, not sure why the issue just started.

Switching to using await supabaseAdmin.storage instead of await supabase.storage DOES fix the issue, but that should not be necessary

[martinbaste]

We have started seeing this today as well, when uploading an image. The code has been in production unchanged for a few months, not sure why the issue just started.

Switching to using await supabaseAdmin.storage instead of await supabase.storage DOES fix the issue, but that should not be necessary

Looking at the code I don't think it ever worked. Are you using the cli setup in prod?

[ShepSims]

We have started seeing this today as well, when uploading an image. The code has been in production unchanged for a few months, not sure why the issue just started.
Switching to using await supabaseAdmin.storage instead of await supabase.storage DOES fix the issue, but that should not be necessary

Looking at the code I don't think it ever worked. Are you using the cli setup in prod?

Yes but we have not pushed a schema change between when this was working and now

[szilard-n]

I'm having the same issue. I use supabase with clerk. It was working a couple of days ago then today I started getting 403 - invalid algorithm. Inserting into the database works, but as soon as I want to upload a file to storage, I run into this issue. I have RLS policies set up for all the tables and storage.

[ivanlewin]

I am also having the same issue with my Supabase-Clerk integration. I resorted to fetching a templated token conditionally (only for requests to the storage endpoint). I'll leave this here in case it helps anyone else:

function createSupabaseClient() {
  return createClient<Database>(SUPABASE_URL, SUPABASE_ANON_KEY, {
    global: {
      fetch: async (url, options) => {
        let token: string | null | undefined = null;
        if (isStorageRequest(url)) {
          token = await window.Clerk.session?.getToken({ template: "supabase" });
        } else {
          token = await window.Clerk.session?.getToken();
        }
        const headers = new Headers(options?.headers);
        if (token) {
          headers.set("Authorization", `Bearer ${token}`);
        }
        return fetch(url, {
          ...options,
          headers,
        });
      },
    },
  });
}

[martinbaste]

It'd be great to get a Supabase person here, but I get the impression that the Clerk issue is different and should have a different thread. Just guessing based on the context.

[d-stoll]

Opened a separate issue for the error with Clerk: supabase/supabase#34948

[kallebysantos]

Hi guys, I tried to debug the supabase/cli source code and was able to force AUTH_JWT_ALGORITHM=RS256.
It solves the "invalid algorithm" error but now I'm getting: "secretOrPublicKey must be an asymmetric key when using RS256" - That cames from the jsonwebtoken lib, a dependency from Storage.

I tried to paste my user session token on jwt.io and got "signature verified", All public JWK matches with the ones exported here

[GaryAustin1]

On Clerk stuff:

https://status.supabase.com/incidents/98c41745c964

[itslenny]

The incident impacting Clerk integration (and most 3rd party auth using storage) has been resolved. It was caused by a change that went in to production yesterday. The fix for it has now been deployed in all regions and this problem should be resolved.

However, the issue @martinbaste is facing is separate as it predates this change by a couple weeks. I've passed this issue along to the Auth team to investigate further.

[hf]

@martinbaste Is the issue still relevant?

[martinbaste]

@martinbaste Is the issue still relevant?

Yes, AFAIK no code has been deployed to fix it. So it's still failing to properly authenticate users on Supabase CLI (Storage) when Cognito (and probably other third party auth) is used.

So yes, would be great if the Auth team can take a look. My initial post highlights where I think the issue is, but I'm no expert in the Supabase CLI codebase. I think we're just not passing the right env variables to the Storage docker container.