How to impersonate a user using service role client

[JungeWerther]

Hi. I'm trying to implement a feature using an event driven approach:

• The user stores an object in storage
• This triggers a custom hook which calls a supabase edge function

How can I securely re-assume the existing session token of my user from an edge function? Once I 'pass through' the database, the existing JWT you would otherwise access through client.auth.getUser() or client.auth.getSession() is not longer accessible.

When choosing to secure my edge function, I can use it to create a new service role client.

However there seems to be no API to create a new session if you have service role.

Don't want to be passing this access around and especially don't want to be storing the JWT inside different microservices to sign a new one.

How can I just get a new session with just a service role client and a user id ? in typescript?

[GaryAustin1]

There is no built in way to get a session from the id. Normally you would pass the jwt.

You can use https://supabase.com/docs/reference/javascript/auth-admin-generatelink to generate magic link tokens/otp, then use verifyOtp with the returned otp token to signin as the user.

Note though this is a real signin and if the user signs out on their side that could be impacted and if you signout with default global then the user on the client would also be signed out.

With service role you could just filter with the user id on tables depending on what your goal is. You would bypass all RLS though.

Note also you should have two Supabase clients if you go this approach as the service_role client will become a user client if you signin or set a session in it.

[JungeWerther]

Okay, that is clear. thx So for max reliability just use the service role and filter.When you would pass the jwt like normal, would a user signout also invalidate the token?Also, I was thinking, maybe it's possible to fetch the latest session from the auth schema in the postgres custom hook logic. Dangerous business though as it would probably mean making auth schema accessible via rpc on different schema, increasing attack surface.

[GaryAustin1]

User signout would not invalidate the jwt for the time it is alive. You can't though refresh the jwt from two places so it is only good for quick things. Using the magic link method above creates a totally new user session with its own refresh token that would be refreshed until a signout (global by default) occurs then it would not refresh anymore.

I would not design anything based on what is in auth tables as they have and can change at any point plus your valid comment on rpc calls but you could lock the rpc to service_role to limit exposure.