Supabase Asymmetrical Key Update
Hey team, with Supabase migrating to using asymmetrical keys (https://github.com/orgs/supabase/discussions/29289), and Kinde not being a supported third party auth provider, wondering if you have any suggestions on handling auth now?
I've switched Kinde accounts, therefore need to set up a new custom JWT secret in Supabase but had accidentally migrated to the new keys. Although it is possible to resolve this by creating a new Supabase project, I would prefer not to, just wondering if the team has considered this yet. Would love to avoid having to make an extra network hop to exchange tokens for each auth.
Thanks
GitHub
Supabase Auth: Asymmetric Keys support in 2025 · supabase · Discu...
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 t...
3 Replies
Hi David,
Thank you for reaching us.
Kinde JWT Signing & JWKS Support
Kinde only issues JWTs signed with RS256, which is an asymmetric algorithm. We also expose a public JWKS (JSON Web Key Set) endpoint, which can be used to validate our tokens without needing a shared secret.
You can find your app’s JWKS URL here: https://<your-subdomain>.kinde.com/.well-known/jwks
Supabase JWT Verification Update
Supabase's updated model expects third-party auth providers to supply a JWKS endpoint for verifying RS256 tokens. So instead of using the Custom JWT secret field (which only works with symmetric HS256 tokens), you can now:
Go to your Supabase >project > Auth > Settings > JWT.
Change the JWT verification method to JWKS URL.
Paste your Kinde JWKS URL (https://<your-subdomain>.kinde.com/.well-known/jwks).
Save your changes.
This allows Supabase to validate Kinde-issued tokens natively, no shared secret required, and no need to spin up a new Supabase project.
What You Need to Ensure
Token claims: Kinde's ID or access token must include:
iss (issuer) → https://<your-subdomain>.kinde.com
aud (audience) → This should match what Supabase expects (can often be skipped unless enforced).
sub (subject) → Unique user ID used in Supabase RLS.
RLS policies: Continue to extract the sub claim from the JWT for your row-level security rules. You can follow the same RLS policy example in our existing guide.
https://docs.kinde.com/integrate/third-party-tools/kinde-supabase/#step-5-define-database-policies-in-supabase
No Extra Token Exchange Required
You do not need to exchange tokens or set up an additional backend. Kinde's RS256-signed tokens are compatible with Supabase's new JWKS-based verification model. Just point Supabase to your new JWKS endpoint.
If you've switched Kinde accounts or rotated keys, simply update the JWKS URL in Supabase.
Ref:
https://docs.kinde.com/build/tokens/verifying-json-web-tokens/
https://github.com/orgs/supabase/discussions/29289
Kinde docs
Verifying JSON Web Tokens
Learn how to verify JSON Web Tokens (JWTs) for secure authentication, including signing algorithms, validation methods, and security best practices for protecting your backend APIs.
Kinde docs
Kinde and Supabase
Comprehensive guide to integrating Kinde authentication with Supabase database including PostgreSQL RLS policies, Next.js setup, and secure user-specific data access
This doesn't seem possible with the current Supabase dashboard, these auth providers are seemingly the only spot you would be able to configure JWKS, unless I'm missing something
Thanks for pointing that out, and I appreciate your patience.
You're right, with Supabase migrating to asymmetrical keys and Kinde currently not being one of their supported third-party auth providers, we understand this introduces some friction.
We totally understand the desire to avoid additional complexity, and I’ve shared your feedback with our product team. Our team will be reviewing the impact of Supabase’s changes soon as possible and is exploring options to support this more seamlessly moving forward.