Ant & I are excited to release Supabase Auth. Supabase is an open source Firebase alternative. We are building the features of Firebase using scalable, open sou

Ant & I are excited to release Supabase Auth. Supabase is an open source Firebase alternative. We are building the features of Firebase using scalable, open source products. Back in May one of our users unexpectedly launched us on Hacker News[1]. There were a lot of comments about Auth: many people asking for it, and many wondering how we would implement it. If you don’t care for the details, the linked blog post is more high-level. For anyone interested in the technical details, this is how we implemented our Auth system from the bottom up: Authorization: Supabase is built with Postgres + PostgREST so we were adamant that we’d use PostgreSQL’s row level security[2] for authorization. PostgREST solves most of the hard work with their auth system[3] and Supabase hides the PostgREST implementation when you start a new project. We create a few roles in your database: one “anon” role which is restricted, and one “authenticated” role which users can “assume” once they are logged in. Inside your database, you can then add Postgres Policies[4]. These are incredibly powerful (see Steve’s “social network” database[5]). Admittedly they can be confusing, but we have plans to make them simple. Their flexibility outweighs their complexity in any case. Authentication: After trying many open source tools, we found Netlify’s GoTrue[6]. This was simple and covered most of the functionality we need. There are some missing Oauth clients, so we will contribute them when we roll out Oauth (we only have email login for now). When a user starts a new Supabase project, we create an “auth” schema in their database. GoTrue stores the users and user data in this schema. AuthN+AuthZ: when a user signs up to your app/project, GoTrue assigns them a unique UID, saves them in the auth schema, and returns a JWT with the user’s details. Our client library attached this JWT to every API request. PostgREST validates the JWT then sends the request through to Postgres. Postgres is able to inspect the request header to get the user’s role and UID, but to make this easy we added some helper functions to the auth schema: one to get the logged in user’s UID (`auth.uid()`) and one to get the logged in user’s role (`auth.role()`). These functions can be used in the Postgres Policies to create a very powerful rules engine. Postgres is one of those tools which you love the more you use it. RLS+Policies are no exception here. It’s very cool being able to specify rules in your database and then be carefree in your frontend. We hope you’ll try it out and send feedback. Note - we’re still in alpha! Please be lenient :). There are some missing features (we’ll be enabling email confirmations/password reset in 1 or 2 weeks) [1] Previous Launch: https://news.ycombinator.com/item?id=23319901 https://news.ycombinator.com/item?id=23319901 [2] RLS: https://www.postgresql.org/docs/current/ddl-rowsecurity.html https://www.postgresql.org/docs/current/ddl-rowsecurity.html [3] PostgREST auth: http://postgrest.org/en/v7.0.0/auth.html http://postgrest.org/en/v7.0.0/auth.html [4] Policies: https://www.postgresql.org/docs/current/sql-createpolicy.html https://www.postgresql.org/docs/current/sql-createpolicy.htm... [5] Social network: https://github.com/steve-chavez/socnet/blob/f1abaadaaedb7c8e9a9a57fbe3a555fb767a5266/security/users.sql#L65-L80 https://github.com/steve-chavez/socnet/blob/f1abaadaaedb7c8e... [6] GoTrue: https://github.com/netlify/gotrue https://github.com/netlify/gotrue