Migrating to new asymmetric keys (signing_keys) on local environment.
Hi all,
I am working on the local version of my project before deploying it to production.
I would like to enable the new asymmetric token signing/verification on my local instance, now that this PR is merged: https://github.com/supabase/cli/pull/3841
I have generated the keys with the provided command and then added this line to my
config.toml
However, when I start my Supabase instance through the CLI, I always get an anon key and service role key, instead of the new public key and secret key.
Is there a way to enable this on the local environment? I am using the latest CLI version 2.33.9.
Thanks8 Replies
I still haven't found a way to enable this and there were no instructions with that PR as to how to enable it either. Even on the latest beta version 2.34.1, it's still the same.
Just to be clear though asymmetric token signing and the new API keys are two different things.
Thank you! Let's see if they add some documentation in the future.
@silentworks it works for me on 2.34.3.
you have to copy and paste the output into
supabase/signing_key.json. the file name doesn't matter. just make sure signing_keys_path goes under [auth]works as expected, now even locally, claims verification should use the JWKs
Does it generate a new SUPABASE_KEY for you? because I've tested this version and it still generates the old keys. However when I use the latest beta version (2.38.2) it does generate new keys and it does indeed work.
i’ll have to check
but wait what is that key? anon key and service role keys are totally orthogonal to asymmetric singing. as long as you can verify the JWTs minted by gotrue with the JWKs, then it’s working as expected as far as i’m concerned
in old versions of the CLI, there were no JWKs…
the key you point to in config.toml is generated by the cli; in production, it’s generated by supabase and you never see it
I'm referring to the
anon key that is outputted in the terminal when you run supabase start, not the generated signing_key.json.oh i didn't check if it gives me new keys or not
all i can confimr is that the JWTs can be verified against the JWKs