Verifying Supabase JWT Myself - Bad Practice?

[angus-clark]

I am creating a backend server with micronaut and would like to use the existing supabase auth for my api endpoints. The only way I can think of securing my end points is verifying the supabase access token myself using the JWT_secret.

This requires me to know the algorithm used by supabase (HMAC256) which seems like a possible point of failure. Is this correct?

Is there any other way I can't see to authorize my endpoints in micronaut using supabase?

[GaryAustin1]

It is a common thing to do for API's. Almost any jwt library using the secret will decode and verify the jwt.

[saiorama]

algorithm used by supabase (HMAC256)

If you decode the token at jwt.io, the header says the also is HS256. What made you say HMAC256?

[saiorama]

You're right - I later discovered (after asking here) that HS256 is HMAC-SHA-256. My bad.

In any case, I was facing the same problem as you and figured I'd use the JWT secret to verify user access tokens on the server by using something like @tsndr/cloudflare-worker-jwt (my server is a Cloudflare Worker which doesn't support jsonwebtoken).

This didn't work for me because I don't think the user access tokens returned on login are signed by the same JWT Secret available in your Supabase project dashboard. Every Supabase JWT header includes a kid (key id) which suggests to me that Supabase internally uses an array of secrets to sign payloads for which kid is the index. Instead, since I can use supabase-js on Cloudflare, I'm switching to using supabase.auth.getUser(user_jwt) to check for user's auth status.

I'd love to know where you land on this.

[GaryAustin1]

There is only one jwt secret per project and all user tokens use the same one. You can use that same secret to generate your own compatible jwts. A bit more info. https://supabase.com/docs/learn/auth-deep-dive/auth-deep-dive-jwts

[KensingtonOscupant]

@GaryAustin1 my experiences align with those of @saiorama. I tried decoding the JWT with the JWT secret from the dashboard on my backend with Python using pyjwt like so

import jwt

jwt_secret = 'my_jwt_secret'
token = 'my_jwt'

decoded = jwt.decode(token, jwt_secret, algorithms=["HS256"])

And this always returns jwt.InvalidTokenError. Assuming there is just one JWT secret and it is used to generate the JWTs received as access tokens, that either means that the implementations of both pyjwt and @tsndr/cloudflare-worker-jwt are flawed, or there is a misunderstanding here on how to use the JWT and JWT secret in such libraries.

[saiorama]

@KensingtonOscupant I was able to use the existing secret in the Supabase dashboard to verify JWTs. The issue is that the JWT's encoding has to be reversed (to an extent) before you try to verify it.

As you're probably aware, JWTs are base64 strings (with some differences). Base64 strings have + and / (I think). JWTs replace + and / with - and _ respectively. JWTs also discard any trailing = signs. So, if you want to verify JWTs, you will have to reverse some of these adjustments before verification.

Reverse JWT specific changes in the signature part of the JWT:

1. Replace all - with +
2. Replace all _ with /
3. Pad the JWT back with = if the length is not a multiple of 4.

After this, you should be able to verify the token. Hope this helps.

[KensingtonOscupant]

@saiorama Thank you! Edit: I think I was bit too quick to celebrate here, didn't get it to work. It's true that it is possible to make the payload and header human-readable by decoding it using base64 URL decoding, but I don't think Base64 URL-decoding the signature is a step that would have to be done manually every time before decoding a JWT. I would find it surprising if JWT libraries didn't handle it on their own.

tl;dr: interesting to look into the payload and header, but Base64 URL-decoding the signature doesn't provide info on the authenticity of the issuer

[tigger0jk]

I had the same problem - for me the issue was that I had to verify audience when validating. pyjwt didn't give me a very helpful error but python-jose did.

I plugged my JWT I got from supabase into https://jwt.io/ and found:

• The audience ("aud") is "authenticated" - I believe it's always this for supabase auth

Here is an example in python using pyjwt

pip install pyjwt

import jwt

decoded_token = jwt.decode(token, '<jwt_secret>', algorithms=["HS256"], audience="authenticated")
supabase_user_id = decoded_token['sub']

If you also want/need to verify Authority I wrote about it here https://github.com/orgs/supabase/discussions/4762#discussioncomment-9502775 but that wasn't the case for me

[vikramnirala]

This worked. Thanks

[prad-human-007]

Thanks.

[halchester]

This is a life saver, thank you!

[MbeleLebohang-uct]

The answer found here was more helpful to me.

Basically passing the jwt to this function with verify it

supabase.auth.api.getUser(idToken).

The docs can be found here, see optional parameter.