You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Bug report
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:
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 returnforSigning
andforVerifying
, instead of consuming functions having to know if they should be using thejwtSecret
orJWKS
property.Screenshots
N/A
System information
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: