auth

In Supabase we use a separate Auth server [0]. This stores the user in an `auth` schema, and these users can login to receive a JWT. Inside the JWT is a "role", which is, in fact, a PostgreSQL role ("authenticated") that has certain grants associated to it, and the user ID (a UUID). Inside your RLS Policies you can use anything stored inside the JWT. My cofounder made a video [1] on this which is quite concise. Our way of handling this is just an extension of the PostgREST Auth recommendations: https://postgrest.org/en/v9.0/auth.html [0] Auth server: https://github.com/supabase/gotrue [1] RLS Video: https://supabase.com/docs/learn/auth-deep-dive/auth-row-leve...

{supabase ceo} You can! A lot of people do. Or you can use the Auth server directly: https://github.com/supabase/gotrue

We run a fork of GoTrue, using the migrations in this PR: https://github.com/netlify/gotrue/pull/254 tbh, our fork[1] has deviated a bit from Netlify's so we need to spend some time with them upstream'ing any changes that they would want to merge (perhaps magic links, Azure logins, OAuth scopes). Long term, I think we will need to run 2 different forks because we have different requirements for multi-tenant. So the benefit here would be sharing "OAuth providers" (eg, if we add Okta, we upstream it, if they add Twitter logins, we pull it) [1] https://github.com/supabase/gotrue

Thanks! > magic link We have this one available here: https://supabase.io/docs/reference/javascript/auth-signin#si... We don't have OTP, but that's a great idea - something we can add to GoTrue (https://github.com/supabase/gotrue)