Supabase
Upcoming changes to Supabase API Keys #29260
Replies: 44 comments 76 replies
-
|
Is this live? |
Beta Was this translation helpful? Give feedback.
-
|
It is not live yet. There's been no further timelines, aside from "Q4". |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Peterksharma and @j4w8n, we've updated the discussion:
|
Beta Was this translation helpful? Give feedback.
-
|
It is now. |
Beta Was this translation helpful? Give feedback.
-
|
Dang. I was looking forward to an improved auth flow. |
Beta Was this translation helpful? Give feedback.
-
Dang it me too!!! |
Beta Was this translation helpful? Give feedback.
-
|
Would love to get an updated timeline for this, even if it's Q2/3/4 2025 |
Beta Was this translation helpful? Give feedback.
-
|
Also looking for a timeline here. Any info - is helpful for our roadmap. |
Beta Was this translation helpful? Give feedback.
-
|
Supabase really needs to focus up on this. It's hampering their adoption |
Beta Was this translation helpful? Give feedback.
-
|
@o1Suleyman Don't worry, they'll ship five more AI features that barely work and no one uses, instead. |
Beta Was this translation helpful? Give feedback.
-
|
I found the assistants integration in supabase one the best integration by far. Helps me as I am an SQL noob |
Beta Was this translation helpful? Give feedback.
-
|
Will these custom api keys work for creating a rest api on an edge function and letting user authorize with an api key? |
Beta Was this translation helpful? Give feedback.
-
How can I manually generate the new API keys for an existing project? |
Beta Was this translation helpful? Give feedback.
-
|
@kengokawano you have to generate a new JWT secret. All keys will change and need to be updated where you have applied them. |
Beta Was this translation helpful? Give feedback.
-
|
@GaryAustin1 Are you sure about this? When we did this, it created a new set of legacy anon/service_role keys, rather than the new standard of publishable/secret keys. @kengokawano Based on the discussion, this is not live yet (see this comment: https://github.com/orgs/supabase/discussions/29260#discussioncomment-11612891). |
Beta Was this translation helpful? Give feedback.
-
|
@jhwheeler, Gary is correct in how it's done for an existing project, but you are correct that it won't work yet because they haven't released the feature. I think Gary was just trying to give a straight answer to the question @kengokawano was asking. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I read his question as how to generate new keys currently. Not how to generate THE new keys. Sorry for the confusion. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for clarifying! |
Beta Was this translation helpful? Give feedback.
-
|
Is there an updated timeline for the new keys, if not when can there be one? |
Beta Was this translation helpful? Give feedback.
-
|
Quick question: I have some migrations where I created a Do we just swap out the word Here is the sql: create table "public"."user" (
"id" uuid not null default gen_random_uuid(),
"created_at" timestamp with time zone not null default now(),
"email" text not null,
"first_name" text not null,
"last_name" text not null
);
alter table "public"."user" enable row level security;
CREATE UNIQUE INDEX user_pkey ON public."user" USING btree (id);
alter table "public"."user" add constraint "user_pkey" PRIMARY KEY using index "user_pkey";
grant delete on table "public"."user" to "anon";
grant insert on table "public"."user" to "anon";
grant references on table "public"."user" to "anon";
grant select on table "public"."user" to "anon";
grant trigger on table "public"."user" to "anon";
grant truncate on table "public"."user" to "anon";
grant update on table "public"."user" to "anon";
grant delete on table "public"."user" to "authenticated";
grant insert on table "public"."user" to "authenticated";
grant references on table "public"."user" to "authenticated";
grant select on table "public"."user" to "authenticated";
grant trigger on table "public"."user" to "authenticated";
grant truncate on table "public"."user" to "authenticated";
grant update on table "public"."user" to "authenticated";
grant delete on table "public"."user" to "service_role";
grant insert on table "public"."user" to "service_role";
grant references on table "public"."user" to "service_role";
grant select on table "public"."user" to "service_role";
grant trigger on table "public"."user" to "service_role";
grant truncate on table "public"."user" to "service_role";
grant update on table "public"."user" to "service_role"; |
Beta Was this translation helpful? Give feedback.
-
|
In the middle of their FAQ on this thread they say the following: "By default, secret API keys assume the service_role. When creating the new secret API keys, you can override this behavior and assign a custom role." I'm interpreting this to say that the "service_role" role in Postgres will still be associated with your API key like it is today and we won't need to change any GRANT statements mentioning "service_role". Fingers crossed anyway. |
Beta Was this translation helpful? Give feedback.
-
|
Let's hope! It would be helpful to receive an official response on this matter. |
Beta Was this translation helpful? Give feedback.
-
|
yes , i am also worried about that , my whole project migrations and customization based on service_role . i hope it will not change. |
Beta Was this translation helpful? Give feedback.
-
|
i just tried and it seems to work my functions who are allowed on service_role work the same way |
Beta Was this translation helpful? Give feedback.
-
|
What's the plan for self-hosted via docker? Is it available there already? I did a quick scan but didn't see this in the docker files. |
Beta Was this translation helpful? Give feedback.
-
|
According to the FAQ:
I am using connection strings with Prisma. I just restored a project which was paused for inactivity and can no longer reach it from my application.
Also:
Has this policy changed? The connection instructions in the project show no change in the recommended setup for connecting with Prisma. |
Beta Was this translation helpful? Give feedback.
-
|
Asym jwts have not been released yet, so the timeline is inaccurate. So, theoretically, it shouldn't have affected your project. You might wanna contact support. |
Beta Was this translation helpful? Give feedback.
-
|
Updated timeline posted anywhere? |
Beta Was this translation helpful? Give feedback.
-
|
One day left before the launch week is over... |
Beta Was this translation helpful? Give feedback.
-
|
a very sad outcome I must say |
Beta Was this translation helpful? Give feedback.
-
|
I completely spaced that they were releasing anything today. Oh well, someday. |
Beta Was this translation helpful? Give feedback.
-
|
It looks like they updated the timeline on supabase , previously it said Q4 2024 |
Beta Was this translation helpful? Give feedback.
-
|
Nice find @omarammarthefirst. I finally found where this was at in the dashboard. So the announcement link takes you back to this discussion. |
Beta Was this translation helpful? Give feedback.
-
|
Has anything on this been actioned? |
Beta Was this translation helpful? Give feedback.
-
|
Nothing has been implemented, if that's what you're asking. Supabase-hosted project dashboards say asym JWTs will be available by the end of June 2025. We shall see. |
Beta Was this translation helpful? Give feedback.
-
|
my current (old style) anon key has a start date of june 2025, can i migrate to new keys yet or how do i refresh the old one |
Beta Was this translation helpful? Give feedback.
-
|
I don't think the new keys are out yet, they are looking at a Q2 2025 release I believe, which means it will probably come out around June of this year. |
Beta Was this translation helpful? Give feedback.
-
|
Why must I pass both JWT token and anon API keys to access the PostgREST API? |
Beta Was this translation helpful? Give feedback.
-
|
@kangmingtay Will be be able to create multiple secret keys? It'll help with reducing downtime during key rotation. |
Beta Was this translation helpful? Give feedback.
-
|
Yes! |
Beta Was this translation helpful? Give feedback.
-
|
🫶 |
Beta Was this translation helpful? Give feedback.
-
|
Necesito ayuda 🆘 |
Beta Was this translation helpful? Give feedback.
-
|
Will we still be able to verify users in cloudflare workers (like we were doing with JWTs) without having to connect to supabase? If so a snippet of some kind would be appreciated. |
Beta Was this translation helpful? Give feedback.
-
Before:
New:
I can't say in detail cause never worked on cloudflare workers before, but if it's some nodejs based instance, I assume you are using jsonwebtoken package, which the verification process is exactly the same for symmetric key but using the public key instead of symmetric key 
|
Beta Was this translation helpful? Give feedback.
-
|
Before third party services did not need to connect to supabase - they would use the jwt.verify function you linked using the JWT Secret provided in the UI (or fetchtable from the db via the sql: |
Beta Was this translation helpful? Give feedback.
-
|
The current JWT secret still exists until deprecated well after the transition. The app.settings.jwt_secret was removed along time ago. I don't recall the reason, but I assume for security. Async JWT's have a "reading" secret and a "signing" secret. The signing secret needs to be kept secure and is used to generate JWTs. The public "reading" secret can be fetched at a new endpoint Two benefits are now your potentially exposed secret can't be used to generate a JWT if it leaks and as long as you call the endpoint you don't have to hard code the public secret in your code and deal with changes by hand. I do not know if the public secret will be in the dashboard or not, but don't know why it wouldn't. |
Beta Was this translation helpful? Give feedback.
-
|
When? Tomorrow. 🎉 |
Beta Was this translation helpful? Give feedback.
-
|
Ah I can now see the JWT keys section in the UI... Perfect! |
Beta Was this translation helpful? Give feedback.
-
|
Initial commit |
Beta Was this translation helpful? Give feedback.
-
|
Can some create a video, for the common programming languages, c#, java, dart, js etc for the new api key method. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
That's unfortunate, I'll bring it up with the support team. I will hide this thread now so that the discussion remains on topic. |
Beta Was this translation helpful? Give feedback.
-
|
any one easle face any issues with supabase dashboard management after implementing new keys? "Failed to delete user: |
Beta Was this translation helpful? Give feedback.
-
I believe the realtime monitor is using the anon/service_role key also based on some testing I was just doing. I don't know how that would impact your RLS though, especially as you show service_role which bypasses it. I have tested and do find an issue with the new async JWT's being turned on and realtime not connecting with the new API keys OR with an async JWT in the user session. The realtime monitor though seemed to work fine at least for postgres_changes. Another user is running into the same problem. I've forwarded info to Supabase on it. I do think there may be issues though in general with realtime and the new keys/async JWT's. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, it’s a bit strange that I’m encountering RLS errors while using the service_role key. I haven’t modified anything related to RLS or realtime, everything is still in its default state from the initial project setup -> but I have opt-in for the new API Key and performed a rotation from the legacy. I also initialized a new Supabase project as a comparison, and Realtime works fine from the Dashboard there. On local development, using the JS SDK, I’m able to use channels without any issues. So the problem seems to be isolated to the Dashboard itself, which is also spamming websocket connections repeatedly. 
|
Beta Was this translation helpful? Give feedback.
-
|
Realtime server had an update last night that resolved the async JWT's and new API keys working with async migration done. |
Beta Was this translation helpful? Give feedback.
-
|
My dashboard seems to be using previous JWT still. |
Beta Was this translation helpful? Give feedback.
-
|
The changes that I saw in realtime were just to make sure the new keys work. |
Beta Was this translation helpful? Give feedback.
-
|
Hi. A question: Now it requires the secret key. Is this intentional? |
Beta Was this translation helpful? Give feedback.
-
|
Hi having an issue where after creating a secret API key (and having legacy jwt secrets disabled), using it with the supabase client in the python SDK returns "Invalid API Key". This error disappears when reverting back to old service_role key. My Next app, however, only works with the new publishable API key, and authN fails when providing the old anon key. It seems others are having similar issues with authorization when using the new API keys. |
Beta Was this translation helpful? Give feedback.
-
|
same issue, any fix? |
Beta Was this translation helpful? Give feedback.
-
|
Edge function call with new ES256 jwt tokens fails with "Legacy API keys are disabled" error. My setup
Additional things I tried:
What is the correct set up for Edge function then? I would still like to have the jwt key passed so that I can retrieve the user id ("sub") and make additional queries in the database. It appears re-enable the legacy JWT token solves the issue, but it does not appear to be recommended. I also do not know if there will be conflicts if both systems are present and which one will take priority. |
Beta Was this translation helpful? Give feedback.
-
|
Also, if we deploy without |
Beta Was this translation helpful? Give feedback.
-
|
I had a similar error while trying to use an edge function with Auth Hook. |
Beta Was this translation helpful? Give feedback.
-
|
My project currently using nextjs and I have followed the supabase SSR manual for authentication. I have public URL i use and an anon key. Can I replace the anon key with the publishable key and everything should work as is? |
Beta Was this translation helpful? Give feedback.
-
|
J |
Beta Was this translation helpful? Give feedback.
-
|
I am no longer able to generate types using
|
Beta Was this translation helpful? Give feedback.
-
|
With the recent switch to asymmetric JWTs and the new API key generation UI, it seems we can no longer generate tokens with custom roles. Previously, I used a script to sign JWTs with a custom role for backend workers: import { SignJWT } from 'jose'
const secret = new TextEncoder().encode(process.env.SUPABASE_JWT_SECRET)
const signedJwt = await new SignJWT({ role: role })
.setProtectedHeader({ alg: 'HS256' })
.setExpirationTime('10y')
.sign(secret)In the initial post of this discussion, it was announced:
However, it looks like this feature was removed before the final release (I noticed @hf edited the OP to remove this mention). Is there a timeline or plan to support assigning custom roles to secret API keys? This would be welcome to increase the security of some of our backend workflows. |
Beta Was this translation helpful? Give feedback.
-
|
Hi,
|
Beta Was this translation helpful? Give feedback.
-
|
Are publishable keys available on local studio now? |
Beta Was this translation helpful? Give feedback.
-
Can someone explain You will need to apply this option to functions you are protecting without it.? What are the steps needed to migrate the user-check step in an edge function? I'm creating a client with user privileges, then getting the user ID as follows, but I keep getting export function getSupabaseUserClient(request: Request): SupabaseClient {
const authorizationHeader: null | string =
request.headers.get('Authorization');
if (!authorizationHeader) {
throw new ApiError('Authorization header is not set.', 401);
}
return createClient(
Deno.env.get('SUPABASE_URL')!,
Deno.env.get('SUPABASE_ANON_KEY')!,
{
auth: { persistSession: false },
global: { headers: { Authorization: authorizationHeader } },
},
);
}export async function getUserId(
supabaseClient: SupabaseClient,
): Promise<string> {
const { data, error } = await supabaseClient.auth.getClaims();
if (error) {
throw error;
}
if (!data) {
throw new ApiError('User was not found.', 404);
}
return data.claims.sub;
} |
Beta Was this translation helpful? Give feedback.
-
|
I would also like some clarification on this. When you attempt to rotate keys, there is a popup with a checkbox to acknowledge that edge functions may stop working. This is the help text displayed in a popup:
Is this related? Can we get an example of how we might implement the verification logic in our function's code? Maybe also an explanation on why this is necessary? I would prefer to let the framework continue to verify authentication for me, there are less chances for mistakes or a bad implementation that way |
Beta Was this translation helpful? Give feedback.
-
|
@mark-monteiro Take a look at this comment. You can still use whatever framework for verification as long as it supports using a JWK URI (e.g. Here is an example from the jsonwebtoken library's docs: // Verify using getKey callback
// Example uses https://github.com/auth0/node-jwks-rsa as a way to fetch the keys.
var jwksClient = require('jwks-rsa');
var client = jwksClient({
jwksUri: 'https://sandrino.auth0.com/.well-known/jwks.json'
});
function getKey(header, callback){
client.getSigningKey(header.kid, function(err, key) {
var signingKey = key.publicKey || key.rsaPublicKey;
callback(null, signingKey);
});
}
jwt.verify(token, getKey, options, function(err, decoded) {
console.log(decoded.foo) // bar
});Some frameworks handle all of that automatically for you though. For example, And the |
Beta Was this translation helpful? Give feedback.
-
Can we get some additional clarification on how this check is performed? I am using the supabase-js client in the Google Apps Script runtime environment and this error popped up when trying to switch from the old To be clear, this is not a browser environment, it is a server cloud-based runtime environment. |
Beta Was this translation helpful? Give feedback.
and others
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
We’re changing the way API keys work in Supabase to improve your project’s security and developer experience. Refer to the timetable below for key dates and info on actions you may need to take in the future.
This change starts out as early preview and is opt-in. No action necessary until at least 1st November 2025. We strongly encourage you to give the new API keys a try!
What's the change?
These are the planned changes for the API keys:
anonandservice_rolekeys remain available for use.sb_publishable_...can be used to replace theanonkey.sb_secret_.... You can also choose not to have a secret key if you don’t need one. Secret keys replace theservice_rolekey.anonandservice_rolekeys, as needed during the migration period.Summarized, there are 4 types of API keys that can now be used with Supabase. This chart should illustrate it better:
sb_publishable_...sb_secret_...anonservice_roleTimetable
New projects will automatically generate both new API keys and legacy API keys to help ease the transition.
Existing projects can continue to use the legacy API keys and can opt in to use the new API keys by manually generating them.
Feedback and issues seen in the early preview period to be resolved.
Projects restored from 1st November 2025 will no longer be restored with the legacy API keys.
New projects no longer have
anonandservice_roleavailable for use.Why are we doing this?
Since the start of Supabase, the JWT-based
anonandservice_rolekeys were the right trade-off between simplicity and relative security for your project. Unfortunately they pose some real challenges in live applications, especially around rotation and security best practices.The main reasons for making this change are:
anon(low privilege),service_role(high privilege), andauthenticated(issued by Supabase Auth) Postgres roles.Start using the new API keys
It’s easy to start using the new API keys. You can opt in in the Supabase dashboard. This will create the default publishable key and a single secret API key.
For the most part, you can substitute the
sb_publishable_...andsb_secret_...values anywhere you used theanonandservice_rolekeys respectively. They work roughly the same in terms of permissions and data access.You can initialize any version of the Supabase Client libraries with the new values without any additional changes, and we don't expect any backward compatibility issues.
Key differences to be aware of
We've redesigned how the Supabase hosted platform deals with API keys with a few key goals:
To achieve these, the new API keys have some subtle differences from
anonandpublishable:--no-verify-jwtwhich means they can be called without knowing any API key. You will need to apply this option to functions you are protecting without it.Authorizationheader. It is no longer possible to use a publishable or secret key inside theAuthorizationheader — because they are not a JWT. Instead pass in the user’s JWT, or leave the header empty. For backward compatibility, it is only allowed if the value in the header exactly matches the value in theapikeyheader.We believe these limitations are minor and not likely to impact even a single-digit percentage of existing customers. Should you find any additional limitation do not hesitate to bring it up in this discussion or via Supabase Support.
Beta Was this translation helpful? Give feedback.
All reactions