Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JWK not used in signObjectURL #629

Open
Towerful opened this issue Feb 7, 2025 · 0 comments
Open

JWK not used in signObjectURL #629

Towerful opened this issue Feb 7, 2025 · 0 comments
Labels
bug Something isn't working

Comments

@Towerful
Copy link

Towerful commented Feb 7, 2025

Bug report

  • [Y] I confirm this is a bug with Supabase, not with my own application.
  • [Y] I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

Due to Object.signObjectURL (and I think other similar methods) only using the jwtSecret to sign a JWT, I cannot use JWKS (even with a key set that can sign tokens) to provide signed URLs.

I am able to use supabase.storage.from('avatar').download(image) using a JWT signed from Keycloak using an RS256 JWK. So verifying a token is working correctly with JWKS.
My supabase API is behind a proxy that is verifying JWTs against a JWKS provided from keycloak.
As my proxy is verifying JWTs, my service_role and anon tokens have to be signed using asymmetric keys (RS256).
When Studio uses the service_role key to access an item in a bucket, storage-api tries to generate a JWT for it using the jwtSecret - as this is hardcoded. With the algorithm is set to RS256, auth0/node-jsonwebtoken throws an error that the secret is not an asymmetrical key.
So, when storage-api wants to provide a Signed Object URL, it falls back to signing with HMAC.

To Reproduce

Start storage-api with:

AUTH_JWT_ALGORITHM=RS256
JWT_JWKS=#Your JWKS with private key#

wire up studio, try and view a file in a bucket.

Expected behavior

It would be nice if the getJwtSecret checked if the JWK had "key_ops": ["sign", "verify"], indicating that the JWKS is suitable for signing.

Perhaps the getJwtSecret could return forSigning and forVerifying, instead of consuming functions having to know if they should be using the jwtSecret or JWKS property.

Screenshots

N/A

System information

  • Container Image: supabase/storage-api:v1.18.1
  • Running on Kubernetes

Additional context

Add any other context about the problem here.

@Towerful Towerful added the bug Something isn't working label Feb 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant