
Auth is now available in Supabase (YC S20) - kiwicopple
https://supabase.io/blog/2020/08/05/supabase-auth
======
kiwicopple
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.htm...](https://www.postgresql.org/docs/current/sql-
createpolicy.html)

[5] Social network: [https://github.com/steve-
chavez/socnet/blob/f1abaadaaedb7c8e...](https://github.com/steve-
chavez/socnet/blob/f1abaadaaedb7c8e9a9a57fbe3a555fb767a5266/security/users.sql#L65-L80)

[6] GoTrue:
[https://github.com/netlify/gotrue](https://github.com/netlify/gotrue)

~~~
nicoburns
Supabase is pretty exciting. Our product at work was initially hosted on
Firebase, and while there were some really nice aspects to it (auth, realtime
querying) we had a whole host of problems with the limited querying power of
Firebase's non-relational model. So we've gradually been porting everything
over to Postgres (with Hasura for realtime queries).

I have a question about the new auth functionality:

In the blog post it shows configuring auth rules via a GUI. Is there also
support for a code-first approach where these rules are stored in a (sanely
human editable) text format, which is then synced up to the server via a CLI
or similar. I've found that this is absolutely crucial in order to ensure
consistency between dev and prod environments, and to be able to spin up
testing environments.

For that matter, is there an easy way to run the superbase stack locally as a
local dev environment?

~~~
vimota
I'm very excited about Supabase for the same reasons
([https://twitter.com/vimota/status/1201622087888068608](https://twitter.com/vimota/status/1201622087888068608))!
Having Auth is a huge step toward making it an easy replacement for Firebase.

What are the current scaling limitations of Supabase? Do you have a sense of
how many req/s etc it can handle? Firebase has the nice property that it's
really easy to get started but it will scale to millions of users (ignoring
the dev cost of restricted querying), I'm curious how that will work with
managed Postgres.

Are there any plans for a typed/generated client down the line?

~~~
kiwicopple
I see I replied to that tweet - it's a great list of criteria.

> What are the current scaling limitations of Supabase?

We haven't benchmarked it yet, but we have one of our power users doing ~1M
API calls per week. That's on a t3a micro server. Soon, we will give you the
ability to scale up and out. We don't plan to abstract away the database layer
too heavily because it break the "no lockin" promise. We will more likely make
it very easy to run a High Availability cluster (Ant has a background in HA).

> Are there any plans for a typed/generated client down the line?

100%. We're planning a Supabase CLI which will do this (+ give you the ability
to spin up new projects etc).

~~~
vimota
Amazing thank you!

------
webel0
Good on you guys for listening and putting out what seems to be some pretty
awesome auth!

Row level security is far more than I was expecting but exactly the sort of
thing that is needed in a lot of my applications.

I look forward to diving into this more.

------
lukevp
Congrats on adding Auth! Auth + observable data changes + real-time syncing
with row level security in something self-hosted is awesome. Is there a
concept in Supabase of offline data creation, or is it online only? The
offline support of Firebase is really great for a lot of apps where users
create the data (or for example, collecting gps coordinates of a truck).
Anything that doesn’t require an external validator or datasource.

I feel this is a drastically underserved market. I wouldn’t ever use Firebase
and delegate all hosting and scaling of my application to a 3rd party with a
tight coupling all the way down to the front end, without some type of escape
hatch. The way Supabase is a composition of OSS components is really
brilliant!

~~~
kiwicopple
We'd love to build an offline/online solution. It's a bit complex when you
start dealing with conflict resolution but we are already looking at a few
possible OSS libraries to deal with this.

At the moment the leading contender is RxDB
([https://github.com/pubkey/rxdb](https://github.com/pubkey/rxdb)), but it
will require a bit of re-engineering on our end, so we will continue to focus
on the backend features first.

~~~
lukevp
Sounds great, please reach out to me on this from my profile if you’d like to
discuss further. I’ve been using CouchDB/PouchDB for a product, and have
worked with RxDB and Realm as well. RxDB has schemas which may mesh better
with your backend architecture. I think schema-based is the right way to go
personally.

Would be great if the TS definitions could be generated automatically from the
backend with automatic migrations of local data so it doesn’t have to be
replicated again.

Do you have the concept of ephemeral data (data that is not needed for
persistence) or is everything persisted? One example of ephemeral data would
be the users online in a given channel, or the position and range of a shared
cursor in a document collaboration.

~~~
kiwicopple
> Would be great if the TS definitions could be generated automatically

We're working on this! Watch this space

> Do you have the concept of ephemeral data

Everything is persisted right now, so the realtime functionality probably
wont' be great for tracking things like mouse positions. Not sure if we will
ever support ephemeral data, but we really just go where our users ask us. If
there's enough demand, we'll build

------
contravariant
Maybe I'm just not the target audience, but I'm still somewhat confused on
what supabase actually _is_. All I could find was that it was firebase but
open source, which tells me nothing as I'm not overly familiar with firebase
(and firebase's description didn't help me understand which parts supabase
tries to replicate). Literally the only way I could become familiar with
firebase enough to understand how this is a good alternative is if I decide
not to use supabase and go with firebase instead.

~~~
awalias
we provide a layer on top of postgres which includes: auto-generated CRUD apis
that update as you change your schema, a realtime api so you can listen to all
the changes happening in your database over websockets, and now an auth system
to register users and control which data they have access to without having to
write any middleware

what it boils down to is writing apis and connector code to your database can
be a laborious process - we're automating that part away

~~~
contravariant
So am I right in thinking it's essentially an SDK for building CRUD web
applications?

~~~
ies7
My experience with supabase start with their realtime server. An Elixir server
(Phoenix) that allows you to listen to changes in your database via
websockets.

It’s like Postgresql Notify with some extra features like Debezium+Kafka

------
sali0
Really excited about this. I was going to choose Firebase for a new project of
mine but I really hate the inevitable coupling. I am very interested in using
your product, but I am very much a noob at Postgres. How much Postgres
knowledge would be needed to make use of your product? I do plan to learn as
much as I can about it, but I wanted to get your thoughts. Will you be
releasing docs with regards to prerequisite Postgres knowledge, or at least
links to what may be useful to know?

~~~
kiwicopple
We started with the UI because we want to make it simple for anyone to get
started. Our task is to make it so that you don't need any knowledge of
Postgres to get started.

One of the things I'm excited about is our table view - it's just as you would
expect from a database client, but functions more like Airtable. You will be
able to create tables/rows/columns like you would in a spreadsheet.

We still have a lot of work to do to simplify Postgres, but in a few more
months we think we will have something that even non-techies can use

------
gdeglin
Congrats on the launch! I'm a big fan of your approach of making this open
source and deeply leveraging PostgreSQL.

------
eatonphil
Been working on a similar project [0] with a simpler architecture. You supply
a database schema and the project builds you a browser UI and API with
authentication, filtering, pagination, etc.

Authorization is tricky though. I've been looking into high-level compile-to-
SQL languages like TreSQL [1] for expressing more complex logic (e.g.
`notes.get.require: notes.is_public OR (notes->organization.id = $user.id)`).

There's some thinking to be done to flesh out a good language for expressing
policies tied to a user session in SQL.

[0] [https://www.dbcore.org/](https://www.dbcore.org/)

[1]
[https://github.com/mrumkovskis/tresql](https://github.com/mrumkovskis/tresql)

------
kbyatnal
"With policies, your database becomes the rules engine. Instead of
repetitively filtering your queries, you can simply define a rule on your
database table, auth.uid() = user_id, and your request will return the rows
which pass the rule, even when you remove the filter from your middleware."

I'm not sure how I feel about this. With something like authorization, being
explicit is better than implicit. This makes it far too easy for someone to
accidentally forget a policy configuration, but it looks like all your other
queries so it passes code review, and now you have a data breach.

But could be that I'm missing something in how this actually works. Would love
to get your thoughts on it.

~~~
whalesalad
I agree. I would not secure user data with row-level security inside the DB
itself. That’s an application concern and it should live in your application
layer.

It also limits you from replacing the underlying storage engine later on, if
you decide PostgreSQL is not the answer.

I find this to be an unwise architectural decision.

~~~
rvense
But why can Postgres not be promoted to the "application level"? If you
combine it with a few extra tools like an auth service and an HTTP API
adapter, the need for custom backend code is reduced or removed. Your backend
is created declaratively through the schema and policies can be exposed
directly to clients.

I have been thinking about this a lot, recently, due to working on a
greenfields project where I was allowed to think all the foundational
architectural decisions of my past projects through. It's struck me how much
of the tedious code I've written in my career has been due to a few features
in database systems that were either missing or unknown to me (mainly related
to auth and validation). Supabase is exactly the kind of system I have been
working towards.

You can use Postgres as a dumb datastore, but you'll be replicating a lot of
functionality at the "application level" that Postgres already has. And if
you're serious about being able to swap it out for another database, you'll
either be writing a lot of abstractions, or foregoing some of its great
features (e.g. its JSON datatypes) in order to not become too joined to it.

Creating more work for yourself due to some unknown situation that might arise
in the future strikes me as an even more unwise decision than tying yourself
to a flexible, well-known, and proven open source project. It seems no
different than tying yourself to React or Docker or whatever.

~~~
whalesalad
> But why can Postgres not be promoted to the "application level"?

Anything is possible. It can be done. My personal/professional opinion is that
you are shooting yourself in the foot by eliminating what is otherwise a very
handy abstraction between your business machinery and the underlying system
that stores the data.

~~~
programmarchy
That’s not really a handy abstraction though, because you ain’t gonna need it.
The exception being you scale past Postgres in which case you’re going to need
a new architecture anyway. Way better to leverage the robust tooling that
Postgres provides rather than rolling your own. Bravo to Supabase for having
the technical insight to bring that leverage to the mainstream.

------
FanaHOVA
I was always too lazy to add auth to this:
[https://captable.645ventures.com/](https://captable.645ventures.com/)

I might try and do it with Supabase! It's 100% client side right now so it
seems like a good fit. Will report on it when I get a chance to fiddle around
with it. Congrats on shipping!

------
TheTank
Congrats on launching. It looks like it’s only email login. Do you have an
idea when you will release Oauth logins?

~~~
kiwicopple
We're using Netlify's GoTrue
([https://github.com/netlify/gotrue](https://github.com/netlify/gotrue)) for
logins. For the providers they already support (bitbucket, github, gitlab, and
google) we are aiming to release this month.

For other logins, we will contribute back to the repo wherever there is
demand.

------
enumjorge
This is awesome. Auth is such a pain and one of the biggest perks of Firebase
for me. Could you share more details on why you decided to go with GoTrue? I’m
interested in how it stacked up against the alternatives you looked at.

~~~
kiwicopple
We checked out a lot of tools and built POC's with Kratos and KeyCloak

Kratos was very promising but too new/unstable.

We spent a lot of time with KeyCloak, but it had some very heavy server
requirements. We want to be able to release Supabase as a single docker image
and it would have been too difficult with KeyCloak.

We chose GoTrue because it's fairly stable and feature rich, and backed by
Netlify so it's well supported. They didn't have PG support, so we had to fork
it, but otherwise it's been great.

------
agustif
Is graphql support on the roadmap?

Why did you go with elixir for subscriptions?

~~~
kiwicopple
At this stage we don't have plans to support GraphQL. We're a small team so we
have to be very strategic which technologies we choose to maintain velocity.
Since we use PostgREST, we already support many of the key benefits of
GraphQL[1].

That being said, we're big fans of Graphile
([https://www.graphile.org/](https://www.graphile.org/)). Even if we don't
support it ourselves, it would be simple for any dev to point graphile to the
Postgres instance and get a "free" graphql API.

> Why did you go with elixir for subscriptions?

I actually built the realtime server last year to replace Firebase. I needed
websockets (it was for a chat app), so elixir (Phoenix) was the right tool for
the job.

[1] Resource embedding: [http://postgrest.org/en/v7.0.0/api.html#resource-
embedding](http://postgrest.org/en/v7.0.0/api.html#resource-embedding)

~~~
agustif
Yeah that makes total sense (focusing on strategic tech).

Also hadn't thought about plugging in graphile, I guess that makes sense.

I also saw in the repo you don't have TS in mind for now (It could be great
later down with a big codebase)

I'm small contributor to an accounts javascript package (AccountsJS), it can
be used with different dattabases (Mongo, TypeORM, Redis, etc), and transports
(Rest, GraphQL)

In case you might wanna consider it in the future!

~~~
agustif
On the elixir/phoenix choice for WS, I guess that makes sense too, I diped my
toes on eelixir a long time ago after starting learning to code with ruby. It
was cool, but I found a better home at JS/TS.

You can have WS with graphql-subscriptions and postgresql-subscriptions for
example too, all in node/js and frontend with apollo / react or vue or angular
what you like

------
kanobo
It's ironic (but understandable) that Supabase uses auth0 for their auth. How
does Supabase auth compare to just using auth0?

~~~
kiwicopple
We're a big fan of dogfooding - everything in Supabase is built with Supabase
except (as you correctly point out) the Auth.

> How does Supabase auth compare to just using auth0?

Supabase Auth is the result of only 6 weeks of development, so we have a long
way to go to catch up with Auth0 features/stability. We'll get there though!

------
goleary
just an FYI: the first key in the search command shows up as an empty key on
Windows (chrome). So it almost looks like you should hit Space + K even though
I see its actually Control + K.

~~~
kiwicopple
Nice one. The site is built with Docusaurus (v2) - I just upgraded it today to
the new search functionality. I'll fix soon

------
oskarahl
Love the feature preview videos, what did you use to create them?

~~~
kiwicopple
It's called Glitterly - glitterly.app

I saw it on a ShowHN the other day and took a mental note to try it so I could
give the founder feedback. It was very easy to use, definitely recommended.

Also check out this one (on ShowHN now) if you need something more feature
rich: [https://storycreatorapp.com](https://storycreatorapp.com)

