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