Supabase Storage returns 403 “signature verification failed” for service_role request

[EDIPT-Studio]

Hi Supabase community,

I’m investigating a hosted Supabase Storage authentication issue.

A read-only request to the Storage API:

GET /storage/v1/bucket

using the current service_role / legacy credential in both the apikey and Authorization: Bearer headers returns:

403 Unauthorized — signature verification failed

I refreshed the local credential directly from the current Management API service_role listing immediately before testing, and the result was unchanged.

Additional observations:

• The credential is a valid 3-part JWT.
• Its claims include iss=supabase and role=service_role.
• Storage /storage/v1/version responds successfully.
• The project's Auth JWKS endpoint responds successfully.
• No production deployment or database changes were made during testing.

I have opened a Supabase Support request as well.

Question: Is this behavior consistent with a Storage-side legacy JWT verification/key-material synchronization issue? If not, what is the recommended safe diagnostic for distinguishing a Storage verification problem from a problem with the legacy service_role credential?

I will not post any API keys, JWTs, secrets, project identifiers, or other sensitive information.

Thanks.

[GaryAustin1]

Have you tried that service role key with the database REST API?
Not sure what the JWKS endpoint has to do with legacy keys.

Did you revoke the legacy keys?

[EDIPT-Studio]

Thanks — yes, I did test the current service_role key against the database REST API.

Using the same current service_role credential with:

GET /rest/v1/

returned 401, so I don't consider that a useful validation of the key. I did not proceed to infer anything from that result.

And no, I have not revoked or rotated the legacy keys. The service_role / legacy key was obtained from the current Management API key listing and refreshed into my local session before retesting Storage.

You're also right about JWKS — I included it as background on the project's current Auth configuration, but I agree that it doesn't independently validate a legacy service_role key.

The reproducible issue I'm trying to understand is specifically:

GET /storage/v1/bucket

with the current listed service_role key in both apikey and Authorization: Bearer → 403 Unauthorized — signature verification failed.

If there's a better database REST endpoint or supported way to validate the legacy service-role credential itself, I'm happy to test that read-only.

[GaryAustin1]

You should access a table from from the rest/v1 endpoint with this jwt for both apikey and authorization (with bearer) header so see if valid and going to the correct project.

The management API might still show a legacy jwt even if you have turned off legacy jwt support in the dashboard. Check your dashboard settings.

[EDIPT-Studio]

Thanks — your suggestion helped clarify this.

I checked the project settings and found that legacy API keys (anon / service_role) were disabled on September 28. The dashboard shows the active JWT signing key is ECC (P-256).

I then tested the current new secret API key from a non-browser PowerShell request:

• /rest/v1/ → HTTP 200
• /storage/v1/bucket → HTTP 200

So the current API-key authentication and Storage access are working.

The earlier 403 Unauthorized — signature verification failed was from testing the old service_role / legacy credential, which is disabled in this project.

You're also right that the JWKS result wasn't useful evidence for validating the legacy key.

I won't re-enable the legacy keys. I'll now check whether any application/server code still depends on the disabled legacy service_role or anon keys.