Removal of app.settings.jwt_secret from the database

[staaldraad]

Introduction

We are removing app.settings.jwt_secret from the postgres database on 2024/11/22.

This setting has previously been available through our PostgREST integration, and could be accessed using current_setting('app.settings.jwt_secret') in SQL.

Why are we doing this?

The jwt_secret can be used to mint new, custom JWTs and is security sensitive. Supabase limits access to the jwt_secret , through both the dashboard and API, to specific roles (owner, admin and developer). Allowing access to this setting directly in the database can allow bypassing of these restrictions.

What do you need to do?

If you need the jwt_secret, it can be retrieved through the Supabase dashboard.

If you are using the app.settings.jwt_secret in SQL, you will need to update your function to retrieve this value from Vault.

select vault.create_secret('JWT_SECRET', 'app.jwt_secret', 'The jwt secret');

-- retrieve the value, this replaces select current_setting('app.settings.jwt_secret')
select decrypted_secret 
   from vault.decrypted_secrets 
   where name = 'app.jwt_secret';

Also, please consult the changelog entry for Asymmetric Keys to understand the coming changes to jwt_secret and how keys at Supabase are changing.

[rkistner]

@staaldraad While it seems like right now we can still access the secret, the announced date (2024/11/22) is zero notice.

I'm with PowerSync, and we currently rely on app.settings.jwt_secret for integrating with Supabase auth. While I think the new asymmetric keys functionality is a much better way to do this, it is not even available yet.

Is it possible to delay this change until a asymmetric keys have been rolled out, and users had a chance to switch over? As is, this change will break a couple hundred PowerSync projects integrated with Supabase.

[staaldraad]

Hey @rkistner

We understand this is short notice, with security related changes our timelines are shortened. However, this decision was not made blindly and was based on usage data. We reached out to projects where we detected usage of this parameter, it is unfortunate that we did not manage to catch PowerSync in this communication.

The change has been applied to all new projects, and we will soon roll this out to existing projects.

To mimic and maintain the existing mechanism of using current_setting(), the following can be used (although we recommend Vault usage or a table only the postgres user has access to):

As the postgres user:

alter role postgres in database postgres set pgrst.app.jwt_secret to "JWT_FROM_DASHBOARD";

Any new session can then pickup the value via:

select current_setting('pgrst.app.jwt_secret');

This value will not be synced or updated by Supabase. Fortunately, JWT Secret resetting is not a frequent operation.

The changes for Asymmetric JWTs should start becoming public soon and this will include exposing a JWKS end-point, which I believe will allow PowerSync to work without any changes.