Supabase JWT auth for own backend API
Hello, I would like to use Supabase auth for authorizing users into my own api endpoint. I would like to use JWT for that, and as JWTs are already stored in the supabase.auth.session(), I'm considering using these for my own api endpoint. Would it be wise to store the Supabase JWT_SECRET as an ENV variable on my backend?
20 Replies
Basically the secret is stored in servers on the Supabase side also, so yes it is fine to use ONLY on a server with no public access to it.
thanks. I also saw that Supabase's access token is stored as a regular cookie instead of a http-only cookie.
How do you protect against csrf and xss attacks?
I recall an argument here that Supabase stores at localStorage either way, so http-only cookie becomes redundant.
I’m also interested if there’s some short guide on how to harden my site.
But any script can access the localStorage
Yes, that is why their argument of making cookie http-only (to prevent other JS from reading) becomes isunncessary. I'm not sure if I understood their point, correctly
Not sure I quite understand. I would like to prevent any other script from accessing the session_token that supabase-js generates
I am able to log in by setting the cookie in the chrome dev console
Unless Firebase has changed recently, it uses the same approach as Supabase for many years now. There are many discussions on the web about the jwt approach and ways to store the tokens. I have also seen several discussions here and on github.
Here was a recent discussion with Supabase employees commenting, I just searched for with the search tab above with xss as keyword:
https://discord.com/channels/839993398554656828/1024592918985580574/1024725170717479045
I see
thanks!
If you end up looking into refresh tokens and jwts, Supabase uses the rotating refresh token approach.
Basically if you have a jwt good for 10 minutes then if someone steals it they have 10 minutes to use it. The refresh token they stole would also be no good as soon as the app uses it to refresh the jwt, or the user signs out. If a refresh token gets used twice all refresh tokens are invalidated for a user (similar to if they signout on one device, all devices refresh tokens are invalidated).
And where does the refresh token live?
The refresh token is part of the session.
Got it. Should I set the expiration time in the auth settings to x minutes or does the token change automatically every 10 mins until the time runs out?
Jwt (access token) is what expires and is set to 1 hour by default.
Yeah, but does it rotate automatically after expiration or within the expiration time limits?
The refresh token gets rotated (invalidated and new one issued) when it is used. That is how you can log in days later after the jwt has expired. The jwt is no good after it expires.
Got it. Thank you!
Seems like biggest window of vulnerability is if there is an xss attack right after the jwt refreshes and the user shuts down the app (so another app refresh does not wipe the tokens) without doing a signOut. If you steal the tokens a few minutes before they will get invalidated by the app refreshes and after you are out of the app xss can't get to the domains local storage.
But I'm not an expert, and for my apps not worried about it as if I let an xss happen with my coding then I also give access to their password or lots of other data in the app.
@quick_piper15 how do you finally store they key and validate the jwt in your own api backend? I'm curious in that topic, best practices.
Didn't have time to do that yet, but I'll update you
I noticed that https://clerk.dev/blog/how-httponly-cookies-help-mitigate-xss-attacks uses httponly cookies, and that there's a supabase integration for them. might as well try it out
Clerk
How HttpOnly cookies help mitigate XSS attacks
HttpOnly cookies do not prevent cross-site scripting (XSS) attacks, but they do lessen the impact and prevent the need to sign out users after the XSS is patched. HttpOnly cookies are not a substitute for XSS prevention measures.