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.