Supabase Auth: Asymmetric Keys support in 2025

[kangmingtay]

This is now live! Read the blog post.

Introduction

We are introducing asymmetric key cryptography to Supabase Auth in Q4 2024 on 7th October 2024. This will be provided as an additional option to the JWT secret currently shown in the JWT settings page.

Why are we doing this?

Supabase Auth has always been using a symmetric secret (known as the JWT secret) for signing and verifying JWTs. While this is simple and convenient (since the same secret is used for both signing and verifying), it presents the following problems:

1. Extra network request required to verify the user’s JWT with the symmetric secret. Currently, one needs to make a request to Supabase Auth in order to verify the user’s JWT or copy the JWT secret into their environment. While the latter suggestion improves performance, it can result in security implications if the secret is accidentally leaked, which requires all your keys to be rolled.
2. Difficult to roll with zero downtime. Since the symmetric secret cannot be shared publicly, developers need to wrangle with rolling the secret across their environments while ensuring that the new secret is used.

Benefits of using asymmetric keys

Asymmetric keys rely on public / private key cryptography, which means that the private key is only used for signing, while the public key is only used for verifying. This solves the above problems in the following way:

• Usage of asymmetric key cryptography rather than a shared symmetric secret for signing and verifying JWTs. Since asymmetric keys don’t use a shared secret, there is less risk of the secret being leaked.
• Faster JWT verification times since there’s no need to make a network call to Supabase Auth via getUser() . The public key can be used for verifying the JWT. Note that adding the symmetric secret to your server-side environment to verify the JWT also has the same effect but is potentially less secure since there is an increased risk of the secret being leaked if it is used in multiple applications.
• Zero-downtime key rotation. Public keys can be exposed in a JSON Web Key Set (JWKs) format, which allows any one of them to be used for verification. When the asymmetric key is rotated, we can still keep the previously used public key in the JWKs endpoint to verify existing JWTs. New JWTs will be signed by the new asymmetric key.

These will include the following changes:

• A public JWKs endpoint for retrieving the public JWK to verify JWTs. This will be exposed through the https://<project_ref>.supabase.co/auth/v1/.well-known/jwks.json endpoint. The symmetric secret will not be exposed through this endpoint for security reasons.
• A new method called getClaims() , which handles verifying the JWT and returning the claims in it.
• Ability to download the public keys in different formats through the dashboard (e.g. PEM, JWKs).

Migration to Asymmetric JWTs

New projects that are created after 1st May 2025 will be created with an RSA asymmetric key by default. Existing projects can choose to start using asymmetric keys by doing the following:

1. Ensure that you are using the new API keys.

2. Update all your clients to use at least supabase-js version x.x.x (the version number will be updated closer to the release date). In this version, we are introducing a new method called getClaims which handles verifying both symmetric and asymmetric JWTs:

   • Example successful response payload for getClaims()

     {
       "data": {
     	  "iss": "https://projectref.supabase.co",
     	  "sub": "565dafb5-fd66-4274-9c37-f0ff720f5637",
     	  "aud": "authenticated",
     	  "exp": 1824717902,
     	  "iat": 1724717902,
     	  "email": "[email protected]",
     	  "phone": "",
     	  "app_metadata": {
     	    "provider": "email",
     	    "providers": ["email"]
     	  },
     	  "user_metadata": {
     	    ...
     	  },
     	  "role": "authenticated",
     	  "aal": "aal1",
     	  "amr": [
     	    {
     	      "method": "oauth",
     	      "timestamp": 1724717902
     	    }
     	  ],
     	  "session_id": "479c1cbf-bd52-42d4-894f-1519f39b3241",
     	  "is_anonymous": false
       },
       "error": null
     }

   • Using getClaims() to verify the JWT

     import { createClient } from 'supabase/supabase-js'
     
     const supabase = createClient(SUPABASE_URL, SUPABASE_KEY)
     
     // previously, using getUser() requires making an 
     // additional network request to Supabase Auth to verify the JWT
     // 
     // const { data, error } = await supabase.auth.getUser()
     
     // getClaims() will always return the JWT payload if the JWT is verified
     // If it's an asymmetric JWT, getClaims() will verify using the JWKs endpoint.
     // If it's a symmetric JWT, getClaims() calls getUser() to verify the JWT. 
     const { data, error } = await supabase.auth.getClaims(jwks)

3. Create an asymmetric key through the dashboard. At this point the symmetric JWT moves to a Previously Used state. Existing JWTs signed with the symmetric JWT continue to be valid, but new JWTs are signed via the asymmetric JWT. Note: The UI mockup below is subjected to change and is just meant to illustrate the different possible states of a signing key.

4. After the JWT expiry period, you can safely revoke the “Previously Used” symmetric JWT, since new JWTs will now be signed with the asymmetric key.

Frequently Asked Questions

• What do I need to do before I can start using asymmetric keys in Supabase Auth?
  • See migration section above for the detailed steps
• Can I create a symmetric key after I create an asymmetric key?
  • Yes. You will still be able to create a new symmetric key under the JWT settings page in the dashboard. New projects will be created with an asymmetric key by default on 1st May 2025.
• Will the private asymmetric key be exposed?
  • No. Only the public keys will be exposed in various formats (e.g. PEM, JWKs) since those are needed for verification.
• Will I be able to bring my own private key?
  • Yes, you can bring your own private key as long as it complies with the key types allowed.
• What key types can I use to create asymmetric JWTs?
  • By default, asymmetric keys will be created with RS256 by default. You can optionally choose to use ECC or Ed25519. ECC keys are more performant, but not as widely supported as RS256. You can also fallback to HS256 (symmetric keys).

[j4w8n]

This is 🔥

A question though: Given the below,

// getClaims() will always return the JWT payload if the JWT is verified
// If it's an asymmetric JWT, getClaims() will verify using the JWKs endpoint.
// If it's a symmetric JWT, getClaims() calls getUser() to verify the JWT. 
const { data, error } = await supabase.auth.getClaims(jwks)

Is this saying that a naked getClaims() will still require a network request no matter what, but passing in the JWK set with getClaims(jwks) is how to avoid a network request?

import { createClient } from 'supabase/supabase-js'
import { JWKS, SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY } from 'your-environment'

const supabase = createClient(SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY)

const { data, error } = await supabase.auth.getClaims(JWKS)

[kangmingtay]

yes, calling getClaims() without passing in the JWKs will still require a network request to the /auth/v1/.well-known/jwks.json endpoint, however, we'll be able to cache the JWKs in-memory so that subsequent calls to getClaims() don't have to make a request

In some cases (e.g. in a serverless environment), caching the JWKs in-memory may not always work since the function could be run in an isolated execution environment. In such scenarios, the developer can opt to store the JWKs as an env var and pass it in as an argument to always avoid making a network request to the JWKs endpoint.

[tomasmenezes]

Any updates on this?

[kangmingtay]

@tomasmenezes we've just made an update to the discussion:

Update (19th December 2024): Asymmetric Keys will not be released in Q4 2024 because it needs further development work. We will finalize the timeline and announce the updated timeline in Q1 2025.

[ewgenius]

Hello, is there any update on this? getUser performance lag affects us a lot.

[hf]

Switch to getClaims() and use an asymmetric JWT signing key to cut down on the lag ultrasignificantly.

[mayurjobanputra]

Glad to see this coming along. I wanted to integrate Privy.io and asked them about how to do it. They sent me here:

[matthova]

[cobygoldstein]

Hey! Any idea when asymmetric keys will be available? Is there an updated timeline?

[o1Suleyman]

Hey! Any idea when asymmetric keys will be available? Is there an updated timeline?

the PR was merged a few weeks ago, we just need to wait for it to leave RC status

[j4w8n]

Hey! Any idea when asymmetric keys will be available? Is there an updated timeline?

the PR was merged a few weeks ago, we just need to wait for it to leave RC status

Careful. That PR is only introducing a new method to get and verify the claims of a jwt (whether sym or asym); it's not releasing the entire asym jwt feature.

[hf]

It is available now: https://supabase.com/blog/jwt-signing-keys#start-using-asymmetric-jwts-today

[jchiatt]

Any update on the timeline for this? We are trying to decide how to proceed with verifying JWTs for some of our API-to-API requests.

[j4w8n]

It's fairly easy to do your own JWT verification if you need something soon-ish.

There's been no other announcements for when asym jwts will go live, although they said they'd update the timeline this quarter. But announcing a timeline doesn't mean releasing anything, I assume.

[matthova]

+1 to this, we've been patiently waiting for this feature to drop and had to migrate to the following pattern in our API(s)

import * as jose from 'jose';

const { data, error } = await supabase.auth.getSession();

if (error || data == null || data.session == null || data.session.access_token == null) {
  // handle error here
}
const { payload } = await jose.jwtVerify(
  data.session.access_token,
  new TextEncoder().encode(env.SUPABASE_JWT_SECRET)
);
// validate payload or throw

[sanchezcarlosjr]

This feature is a game-changer. It enables better authentication in APIs outside of Supabase and JSON Web Encryption for security-focused apps.

[hf]

Launched! https://supabase.com/blog/jwt-signing-keys#start-using-asymmetric-jwts-today

[matthova]

Update (19th December 2024): Asymmetric Keys will not be released in Q4 2024 because it needs further development work. We will finalize the timeline and announce the updated timeline in Q1 2025.

@kangmingtay there's only about a week left to make a Q1 2025 finalized timeline announcement

[hf]

Done. https://supabase.com/blog/jwt-signing-keys#start-using-asymmetric-jwts-today

[crro]

Are there any updates on the updated timeline? It's already Q2 2025

[hf]

Launched! https://supabase.com/blog/jwt-signing-keys#start-using-asymmetric-jwts-today

[helmut-hoffer-von-ankershoffen]

@kangmingtay Hey Kang, we need to make a decision if to use Supabase or another PaaS - there is no way to use GCP Workload Identify Federation [1] with Supabse without Supabase providing a public JWKS endpoint, afaik. As you see here the community needs an update on the timeline as well. Please provide here, or escalate to your manager :-) Cheers from Berlin

[1] https://medium.com/google-cloud/gcp-workload-identity-federation-with-federated-tokens-d03b8bad0228

[hf]

Are you trying to federate a user into GCP, to call GCP APIs?

[connor-nebulock]

yo. we need this....

[hf]

You have it now. https://supabase.com/blog/jwt-signing-keys#start-using-asymmetric-jwts-today

[hf]

Hey folks, we're soon (days) going to update this announcement. I know all of you have been waiting for this!

[darrynv]

Hey folks, we're soon (days) going to update this announcement. I know all of you have been waiting for this!

Hello wonderful people. Any update? Rough ETA is fine.

[franzvezuli]

Any updates?

[cardilloscreations]

Apparently "days" became "weeks", and now we're over a month since this post. The main thing I want to see is instructions on how to do this with self-hosted once the feature is released and available.

[alita-moore]

to be fair I think we can all relate to making time estimates on software and then being wrong by a factor of 100x

[hf]

Oh with this one the estimation was completely off. If there's interest (👍 on this comment) I can follow up with a blog post of why it took so long and all the challenges along the way.

[hf]

Hey everyone. Sorry to keep y'all waiting. We're announcing this in about 24 hours. 🤞

supabase.com/launch-week

[hf]

It's now been launched! https://supabase.com/blog/jwt-signing-keys

[joseppu]

how do we implement this in local development? I couldn't get any config change to local through linking with remote supabase that migrated.

[cardilloscreations]

When will instructions for self hosted and local development be available?

[joseppu]

on twitter I am told local dev's progress is in this pr below:
supabase/cli#3841

[UliPrantz]

I tried to port my edge functions to asymmetric JWT keys and here are some things that I got stuck with:

1. Local development support (I didn't want to deploy edge functions that I wasn't able to test/verify locally first or debug in any way):

   • Will there be support for local dev keys which are published under http://127.0.0.1:54321/auth/v1/.well-known/jwks.json?
   • Will the runtime environment be hydrated with the Publishable key (API Key) as it was done with SUPABASE_ANON_KEY? If yes, what is the variable name? (if the SUPABASE_ANON_KEY just becomes the Publishable key (API Key) this should be documented)

2. Regarding types are there any plans to add a UserMetadata type as there is a User type to the supabase-js library to make it more obvious which fields are encoded in the claims (specifically in user_metadata). This would also clarify if the fields in user_metadata are always the same or relative to the sign-in method.

3. Generally the edge functions documentation should get an update going more in-depth about the new JWT and the effects on edge function behavior. Also mentioning the new setting in the edge function settings Verify JWT with legacy secret should be highlighted and explained further.

Current Return Values of .getClaims()

supabase.auth.getClaims() has a data field which has a key called user_metadata overall the object looks kinda like this

{
  ...
  "data": {
  ...
    "user_metadata": {
      "email": "[email protected]",
      "email_verified": true,
      "phone_verified": false,
      "sub": "c9e2385d-8f63-45a4-bc78-ebceb5cb9e2b"
    }
  ...
  }
  ...
}

Hono Code to Retrieve Authenticated Supabase Client App

To make things a bit more tangible, here is my current template that I use for new Edge Function endpoints to generate an authenticated Hono app that provides all the variables I need to implement any logic. The question is how could one adapt it to use .getClaims() instead of .getUser() in the createMiddleware function?

import type { createClient , SupabaseClient, User } from 'npm:@supabase/supabase-js@2'
import type { Database } from '../../types/database.types.ts'
import { Hono, Context } from 'npm:hono'
import { createMiddleware } from 'npm:hono/factory'

export type AuthTypes = {
  supabase: SupabaseClient<Database>
  user: User
}

/**
 * Creates a Supabase client with the user's auth context
 * Note: Supabase Edge Runtime automatically validates JWT tokens,
 * so we don't need to handle auth errors here.
 */
function createAuthenticatedClient(req: Request): SupabaseClient<Database> {
  const authHeader = req.headers.get('Authorization') || ''
  
  return createClient<Database>(
    Deno.env.get('SUPABASE_URL') ?? '',
    Deno.env.get('SUPABASE_ANON_KEY') ?? '',
    {
      global: {
        headers: { Authorization: authHeader },
      },
    }
  )
}

const authMiddleware = createMiddleware<{Variables: AuthTypes}>(async (c, next) => {
  const supabase = createAuthenticatedClient(c.req.raw)

  const token = c.req.raw.headers.get('Authorization')?.replace('Bearer ', '')
  const { data, error } = await supabase.auth.getUser(token)
  
  c.set('supabase', supabase)
  c.set('user', data.user!)
  
  await next()
})

/**
 * Create a new Hono app with authentication and CORS middleware
 * Note: Supabase Edge Runtime automatically validates JWT tokens
 */
export function createAuthenticatedApp(basePath = ''): Hono<{
  Variables: AuthTypes
}> {
  const app = new Hono<{
    Variables: AuthTypes
  }>().basePath(basePath)
  app.use('*', authMiddleware)
  app.onError(errorFunction)
  return app
}

[hf]

Regarding types are there any plans to add a UserMetadata type as there is a User type to the supabase-js library to make it more obvious which fields are encoded in the claims (specifically in user_metadata). This would also clarify if the fields in user_metadata are always the same or relative to the sign-in method.

We can't do much on this, as you're in complete control of the claims inside the JWT: https://supabase.com/docs/guides/auth/auth-hooks/custom-access-token-hook

Maybe we add a way to override the type there to match your customizations.

[j4w8n]

Regarding converting from getUser to getClaims, here is how I've mapped things. You'd add any custom properties of course.

const { data, error } = await supabase.auth.getClaims()

// handle this in your own way
if (error || !data) {}

const { claims } = data

const user = {
  app_metadata: claims.app_metadata ?? {},
  aud: 'authenticated',
  created_at: '', // only found in getSession or getUser
  id: claims.sub,
  user_metadata: claims.user_metadata ?? {},
  is_anonymous: claims.is_anonymous
}

[UliPrantz]

@hf and @j4w8n thanks for your input :)

I also came across this documentation here in the Supabase docs which explains some of the Symmetric vs Asymmetric implementation details well! (especially the last FAQs)

[jdgamble555]

I think the problem is that getClaims.data.claims is not sufficiently typed.

I had to do this to simplify:

const user = {
    ...claims,
    id: claims.sub
} as unknown as User;        

J

[jperasmus]

@hf This is an exciting upgrade to Supabase Auth!

Is there an equivalent of the previously available email_confirmed_at field in the new claims JWT payload? We rely on it to know whether someone verified their email.

===

Edit: There is no equivalent claim available in the JWT payload by default. I figured I could use the custom access token hook and then expose it myself by doing a lookup against the auth.users table.

[tadeumaia]

Anyone took a try to update their nextjs/ssr implementation with the new method? Would love some pointers to update this.

• Are you updating on just the middleware
• Are you changing all your pages verification to the getclaims instead of the getuser()?

[hf]

Yup @dalkommatt!

Don't forget getClaims() works with the JWT, not the user object (similar but also customizable). If you're new to JWTs, please read up on them here: https://supabase.com/docs/guides/auth/jwts

[tadeumaia]

getUser() also deal with refreshing the token right? will getClaims() do the same or do we need to do it manually?

[GaryAustin1]

getUser() also deal with refreshing the token right? will getClaims() do the same or do we need to do it manually?
Looking at the source code for getClaims it does do a getSession call which should refresh the token IF expired. It would be good to see that documented though.

One thing that does appear different is that getUser actually returns the auth.users table columns AND I think checks if the user session is valid. This means that if you signout, getUser would know. I don't think getClaims would unless your client object is cleared of the session. The JS client does that. Not sure about SSR server clients. Also getUser does return more info than in the JWT if you depended on other columns in the user object.

[j4w8n]

getUser() also deal with refreshing the token right? will getClaims() do the same or do we need to do it manually?

@tadeumaia I'm not sure @GaryAustin1 addressed this directly in his response. UPDATE: oh, yes he did; it just got thrown into the quoted text and I missed it until now.

Yes, a "blank" getClaims() will refresh the token if needed, because it calls getSession() under the hood, to get the access token for verification and decoding.

However, if you pass the access token yourself - getClaims(access_token) - this will NOT refresh the token if expired. In this case, it'll actually throw an error if it's expired. To allow expired access tokens in this situation, and avoid a thrown error, you can pass an option:

const { data, error } = await supabase.auth.getClaims('the-token-string', { allowExpired: true })`

[tadeumaia]

Great thanks! I will start experimenting updating a nextjs ssr project now with those information. Im having so much problem with invalid or missing refresh token on this flow with users getting signout or getting into weird loops/state they can't re-login, this approach passing the token and controlling the error might help me deal with that.

[drbscl]

Update: resolved

I tried to opt-in today, but get the following message:

JWT signing keys are coming soon
We're rolling out JWT signing keys to better support your application needs.

When will this be generally available?

[hf]

Hey where are you seeing these messages?

It is generally available since Monday: https://supabase.com/blog/jwt-signing-keys

[drbscl]

Thanks for the quick response. Maybe I was hitting a cache, refreshed just now on the JWT Keys page, and I see the button.

[zakzackr]

Hello everyone,

I'm currently integrating Supabase Auth into my application. Specifically, I'm trying to use supabase.auth.getClaims() instead of supabase.auth.getUser() to enhance performance and improve user experience. However, I'm uncertain whether getClaims() is suitable for Next.js middleware using supabase-ssr, as shown below.

import { type NextRequest, NextResponse } from "next/server";
import { updateSession } from "@/lib/supabase/middleware";
import { createServerClient } from "@supabase/ssr";
import { AppUser } from "@/types/user";

/**
 * Main authentication middleware handler.
 * @param request - Incoming NextRequest object.
 * @returns NextResponse - Response after handling authentication logic.
 */
export async function authMiddleware(request: NextRequest) {
    let supabaseResponse = NextResponse.next({
        request,
    });

    // Create Supabase server-side client
    const supabase = createServerClient(
        process.env.NEXT_PUBLIC_SUPABASE_URL!,
        process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
        {
            cookies: {
                getAll() {
                    return request.cookies.getAll();
                },
                setAll(cookiesToSet) {
                    cookiesToSet.forEach(({ name, value, options }) =>
                        request.cookies.set(name, value)
                    );
                    supabaseResponse = NextResponse.next({
                        request,
                    });
                    cookiesToSet.forEach(({ name, value, options }) =>
                        supabaseResponse.cookies.set(name, value, options)
                    );
                },
            },
        }
    );

    const { data, error } = await supabase.auth.getClaims();
    let user: AppUser | null = null;

    if (error || !data || !data.claims) {
        // Refresh Supabase session (token refresh)
        // updateSession() internally calls getUser()
        ({ supabaseResponse, user } = await updateSession(request));
    } else {
        // Construct user object from claims
        user = {
            id: data.claims.sub,
            username: data.claims.username,
            avatar_url: data.claims.avatar_url,
            role: data.claims.role || "user",
        };
    }

    const pathname = request.nextUrl.pathname;

    // Access control for protected pages
    if (PROTECTED_PATHS.some((path) => pathname.startsWith(path))) {
        if (!user) {
            ...
        }
    }

    // Access control for auth pages (authenticated users)
    if (AUTH_PAGES.includes(pathname)) {
        if (user) {
            ...
        }
    }

    // Return response with potentially updated session
    return supabaseResponse;
}

Is it considered best practice to first validate the JWT using getClaims(), and if that fails, call getUser() within updateSession() to refresh the session in Next.js middleware?

I've gone through the public resources, but I'm still having trouble understanding how to properly implement the getClaims() method in my application. I would really appreciate any guidance or feedback you can provide.

[zakzackr]

@j4w8n Thanks for the detailed explanation!

Based on what I’ve tested locally (though I still need to double-check), when the user is signed out or deleted, getClaims returns null. While I assume there will still be cases where getUser is necessary, I believe getClaims can replace getUser in many situations.

I’ll continue investigating as I develop my app. Thanks again!

[GaryAustin1]

If you signout on the same client then yes it would know.
But it is just looking at the JWT from the session in the client otherwise.
If you delete the user from the dashboard or a server the JWT in the client you are doing getClaims on will not know. It can't as it is not checking with the server.

Same goes for a signout from a different client. The JWT is still in the current client as part of the session, so getClaims just looking at that won't know another client signed out.

[zakzackr]

@GaryAustin1 Thanks for the clarification. You are right, and I think I was missing the point.

The official docs state that the SIGNED_OUT event is triggered when "User has signed out on another device", so I initially thought that listening for the SIGNED_OUT event via onAuthStateChange (along with getClaims) would allow a client to detect if another client has signed out.

However, as mentioned in this issue #902, the SIGNED_OUT event is not currently triggered when signing out on a different device, so using getUser() might still be necessary. Also, since onAuthStateChange does not receive any events when a user is deleted from the dashboard, it seems that getUser() is required to detect user deletion as well.

[j4w8n]

I clarified the "signout" bullet point. Thanks!

[j4w8n]

Also, to make sure this is clear, most of what I've said assumes you're using asymmetric signing keys for JWTs.

If you're using symmetric still, then getClaims calls getUser under the hood. It will also call getUser in the below circumstances - I assume some of which could be true even in an asymmetric situation; eg no access to crypto.subtle

[currents-david]

Hi, is there a way to revert back to the legacy JWT secret?

I need to create a new custom JWT secret provided by an external auth provider.

I've migrated a project to the new JWT signing keys, but since I am using Kinde for auth, which is not a supported third party auth provider, I am unable to authenticate requests without doing an unideal key exchange.

[hf]

Create a new signing key, import the private key / secret, and keep the legacy JWT secret (Supabase) in previously used.

[jesuzon]

I've moved over to getClaims on my React Router 7 / Remix application. If anything, I am seeing a performance deterioration compared to the way I was doing things previously - let me explain:

Prior to getClaims, I did things on my own environment without hitting the Auth server as follows:

import * as jose from 'jose';

const { data, error } = await supabase.auth.getSession();

if (error || data == null || data.session == null || data.session.access_token == null) {
  // handle error here
}
const { payload } = await jose.jwtVerify(
  data.session.access_token,
  new TextEncoder().encode(env.SUPABASE_JWT_SECRET)
);
// validate payload or throw

This meant that at the server level, we just used the cookie on the request, got the JWT, and verified it using the legacy JWT secret that we stored in env. Of course, the legacy JWT secret has a nonzero chance to leak, so I understand the security implications of this approach. For this reason, I decided to move over to the new asymmetric keys, as not only it would make the code easier to maintain, it would also come with the security benefit.

However - in my case getClaims keeps hitting the server for the key with every invocation. I can't get my supabase client to cache the key. I am using the SSR client, and therefore creating a new server client for each invocation (as recommended by the docs if I remember correctly). Maybe this is why the key is not being cached.

To clarify my question - Does getClaims, when used with the SSR client, give you the performance benefit of not having to hit the Auth servers due to caching of some sort? If so, how does this caching work? - I guess an option might be to cache the key ourselves, but this should be stated and documented.

[hf]

Documented here: https://supabase.com/docs/guides/auth/signing-keys#public-key-discovery-and-caching

Caching, like in all places, depends a lot on runtime. Vercel Fluid compute has persistent RAM, and we've optimized the latest versions of auth-js to have a secure and global cache, despite creating a client for each request.

[j4w8n]

So are you saying that even if a network request is made, you're likely to get a faster response from the Supabase cache versus the request needing to go all the way back to your Supabase instance?

[j4w8n]

@jesuzon based on the testing I just did and hf's comment, you're still better off to just call getClaims() even though it's making a network request each time.

Below are my results. Each "remote" is hitting the internet, but mostly not my Supabase instance because the global cache hf mentioned is responding.

[jesuzon]

@hf yeah I read that - it doesn't really cover the nuances of how the cache works. It just says the client may cache the jwks.
In my current development environment (Running React Router 7 on Node), creating a server client using the SSR package on route loaders wherever I need to check that the user is authenticated, getClaims makes a network request and the latency is around 100 ms as per my post.

As for this part:

"Caching, like in all places, depends a lot on runtime. Vercel Fluid compute has persistent RAM, and we've optimized the latest versions of auth-js to have a secure and global cache, despite creating a client for each request."

I checked out that packaged and saw that 2.71 introduced this global cache, and this was included in @supabase/supabase-js 2.51. I was on 2.50 and was hopeful the update would help, and it kinda did? - the latency went down to about 50-75 ms rather than around 100 ms, but not the 1-5 ms see others post about, so this may simply be variation. I do indeed see that the GoTrueClient.js file now has :

const GLOBAL_JWKS: { [storageKey: string]: { cachedAt: number; jwks: { keys: JWK[] } } } = {}

I'm not sure what I'm doing wrong, maybe I'm measuring wrong? - this is how I'm conducting the test:

	const start = performance.now();
	const { data, error } = await supabase.auth.getClaims();
 	const end = performance.now();
 	logDebug(`Supabase getClaims took ${end - start}ms`);

I'm not really sure where to go from here

--EDIT:
I decided to patch the auth-js package to include a console log in this location:

        // jwk exists and jwks isn't stale
        if (jwk && this.jwks_cached_at + constants_1.JWKS_TTL > now) {
	    console.log('[GoTrueClient] JWKS served from global cache', { kid, cachedAt: this.jwks_cached_at })
            return jwk;
        }
        // jwk isn't cached in memory so we need to fetch it from the well-known endpoint
	console.log('[GoTrueClient] JWKS fetched from server', { kid })

It turns out, my application IS indeed using the global cache after the first invocation - still, I don't understand why my latency is much higher than @j4w8n and what was shown in the recent video posted about the new asymmetric keys.

--EDIT 2:
I'm not entirely sure what happened, but through adding performance.now checks in several places within auth-js, I found that the source of latency in my case was the getSession() call inside getClaims. This didn't make sense to me, as all that does is read from the storage attached to the supabase client (in my case, cookies in the request). I went to my supabase server client boilerplate to add further timings, and by adding some performance.now checks there too (and breaking my code in the process), it seemed to fix it? It is all very bizarre... I wonder if my cookie was in some way corrupted and getSession was having trouble parsing it, and by breaking my code temporarily, a new cookie was set?

In any case, I can confirm that getClaims() uses a global cache for the jwks, and it continues using this in all newly invoked server client instances for as long as the cache is valid. The latency is minimal (1-5 ms as quoted previously).

I will leave this here in case anyone in the future goes down the same rabbit hole as me...

[silentworks]

@hf can you clarify the Vercel statement in your comment please? does this mean that if my project isn't hosted on Vercel I won't get the caching you mention? If so is there something in place for my app that is hosted outside of Vercel?

[eybel]

Hey there! I am testing this getClaims() thing. It took me a while to understand that the session is till needed but anyways I just wanted to share my new approach because it took me a few hours to understand the following:

1. one the first app load, "on Init" has to be the session based since getClaims() needs to have a session working before and loading data.
2. getClaims() works for subsequent "requests" by not going (again) to the supabase server and retriving the data
3. getClaims() should check for expiration tokens to kick out the user if needed becauase it wont work on sessions.
4. if you want to kick out a client banned inmediatly, I think you should implement getUser(), getSession() in an AuthGuard to protect guards in "sensitive parts" since the getClaims() wont know the session was terminated.

Am I wrong?

NOTE: There is a report that with this migration to the JWT keys, we can't generate types anymore but there is an opened post for issues anyways. "failed to retrieve generated types......"

Thank you team for improving Supabase on a daily basis. (I hope it stays affordable)

[tadeumaia]

I did not see any decrease of auth requests at all migrating to getClaim(), I'm with the new key latest supabase-js on next.js
Only 2 places call getclaims, the middleware and a authorization check at the start of every page.

[jdgamble555]

There are other places in the code that need to be fixed that still call getSession under the hood

supabase/auth-js#873 (comment)

https://github.com/supabase/auth-js/issues/888#issuecomment-2686717971

I suspect that is the issue.

J

[danhnguyen-agilityio]

The getClaims method doesn’t support refreshing data when a user’s metadata changes.
If the user’s metadata is updated, getClaims will not return the latest information.
Is that right?
If so, is there a way to have fresh user metadata while still using the getClaims method?

[UliPrantz]

My understanding is that getClaims is a simple JWT verification check - it only checks whether the token at hand is still valid and if not it gets a new one. So as long as your token is valid getClaims will return the data as it was when the token was granted. If you want to make sure that you have the latest data you must call getUser.

[danhnguyen-agilityio]

Thank you for the information.
After checking further, I found that the getUser method does both of the following:

• Verifies whether the token is valid (similar to getClaims)
• Retrieves and returns the latest user data