Liveview and Supabase Auth access_token

Hi everyone,

I’m finding myself kinda paralyzed over this issue of authenticating (signup/login) an user in my Liveview+Supabase project. Mostly due to where to put the access_token (and refresh) that supabase gives me.

Supabase offers its own auth system with an api on top for user registration/login, it uses JWTs. In my project I have an UserController that calls the login endpoint with the credentials provided. I’m unsure if this is a good approach cause here the client sends the credentials to the server, the server calls the supabase api and gets the access_token, then where to store this access_token?

I’m using ecto with supabase so it’s kinda seamless from using any other postgres db (which is awesome), but I’m stuck on how to use and store these access_tokens for future queries after I login.

Perhaps should I just ignore the auth system and do it myself with phx.gen.auth and create my own users tables on the supabase postgres?

I’m thinking about just dropping the Auth api from supabase and use it as a pure Postgres DB with ecto. So I will just use phx.gen.auth for my auth system. At that point I’m not sure if it’s convenient to still use supabase instead of my own DB, but money-wise it seems it’s still better to use supabase. It has a free tier and a 25$ tier, while most hosting solutions cost way more to just reach the hardware in the 25$ tier.

I had recently the same question but with Firebase.

Where I’m at now is that I use Firebase only to log in the user (keeping it client side via a LiveView hook), verify the returned JWT at the backend level and then use Guardian and its own generated JWT to keep the user logged. That way I use Guardian plugs & helpers.

It’s a bit involved, especially as Phoenix doesn’t have built-in auth(s) support but it seems to work OK.

As for LiveView I stumbled upon “live_session” randomly and it’s useful. Read Live sessions in action · Fly to know more.

To be honest if I only wanted to support email/password I would have probably used the (meh) Phoenix auth generator.

1 Like

I think I was in the direction of your solution. After a day of confusion I thought about using the auth api on the client side and pass the access_token to the server, then use it somehow to authenticate the user in my app for the routes. I found out about guardian to do authentication as well. Then I backtracked and gave up on the auth api cause I was getting nowhere.

Knowing someone else went through the same problems and managed to make it work gives me confidence to try it again. So thanks for the reply! I think I will go the same route so I can take advantace of the social logins and so on.

Storing the access_token securely on the client-side is a common approach. You can use cookies or local storage. Including the access_token in requests’ headers (Bearer scheme) is necessary.
Whether to use Supabase’s auth system or create your own depends on your specific needs and preferences.

1 Like