-
-
Notifications
You must be signed in to change notification settings - Fork 272
Description
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.