mirror of
https://github.com/supabase/supabase.git
synced 2026-10-10 03:45:06 +03:00
0xflotus
4ee6c09295
referring to [January 2021 News](https://supabase.io/blog/2021/02/02/supabase-beta-january-2021)
179 lines
6.5 KiB
Plaintext
179 lines
6.5 KiB
Plaintext
---
|
|
id: auth
|
|
title: Auth
|
|
description: Use Supabase to Authenticate and Authorize your users.
|
|
---
|
|
|
|
### User Management
|
|
|
|
Supabase makes it simple to manage your users.
|
|
|
|
<video width="99%" muted playsInline controls="true">
|
|
<source src="/videos/auth-zoom2.mp4" type="video/mp4" muted playsInline />
|
|
</video>
|
|
|
|
When a user signs up, Supabase assigns them a unique ID. You can reference this ID anywhere in your database. For example, you might create a `profiles` table referencing the user using a `user_id` field.
|
|
|
|
Supabase provides the routes to [sign up](/docs/client/auth-signup), [log in](/docs/client/auth-signin), [log out](/docs/client/auth-signout), and manage users in your apps and websites.
|
|
|
|
|
|
### Third Party Logins
|
|
|
|
We currently support the following OAuth providers:
|
|
- Google
|
|
- Github
|
|
- Gitlab
|
|
- Azure
|
|
- Facebook
|
|
- Bitbucket
|
|
|
|
|
|
|
|
You can enable providers by navigating to Authentication > Settings > External OAuth Providers and inputting your `Client ID` and `Secret` for each.
|
|
|
|
To fetch these you need to:
|
|
|
|
1. Generate `Client ID` and `Secret` ([google](https://console.developers.google.com/apis/credentials), [github](https://github.com/settings/applications/new), [gitlab](https://gitlab.com/oauth/applications), [bitbucket](https://support.atlassian.com/bitbucket-cloud/docs/use-oauth-on-bitbucket-cloud/))
|
|
2. Enter Authorized Redirect URI: `https://<your-project>.supabase.co/auth/v1/callback` on provider dashboard
|
|
|
|
### Row Level Security
|
|
|
|
Authentication only gets you so far. When you need granular authorization rules, nothing beats PostgreSQL's [Row Level Security](https://www.postgresql.org/docs/current/ddl-rowsecurity.html). Supabase makes it simple to turn RLS on and off.
|
|
|
|
<video width="99%" muted playsInline controls="true">
|
|
<source src="/videos/rls-zoom2.mp4" type="video/mp4" muted playsInline />
|
|
</video>
|
|
|
|
|
|
### Policies
|
|
|
|
[Policies](https://www.postgresql.org/docs/current/sql-createpolicy.html) are PostgreSQL's rule engine. They are incredibly powerful and flexible, allowing you to write complex SQL rules which fit your unique business needs.
|
|
|
|
<video width="99%" muted playsInline controls="true">
|
|
<source src="/videos/policies-zoom2.mp4" type="video/mp4" muted playsInline />
|
|
</video>
|
|
|
|
With policies, your database becomes the rules engine. Instead of repetitively filtering your queries, like this ...
|
|
|
|
```js
|
|
const loggedInUserId = 'd0714948'
|
|
let { data, error } = await supabase
|
|
.from('users')
|
|
.select('user_id, name')
|
|
.eq('user_id', loggedInUserId)
|
|
|
|
// console.log(data)
|
|
// => { id: 'd0714948', name: 'Jane' }
|
|
```
|
|
|
|
... 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:
|
|
|
|
```js
|
|
let user = await supabase
|
|
.from('users')
|
|
.select('user_id, name')
|
|
|
|
// console.log(data)
|
|
// Still => { id: 'd0714948', name: 'Jane' }
|
|
```
|
|
|
|
### Policies are like where clauses.
|
|
|
|
Policies are easy to understand once you get the hang of them. You can just think of them as adding a `WHERE` clause to every query. For example if you had a policy like this:
|
|
|
|
```sql
|
|
create policy "Individuals can view their own todos." on todos for
|
|
select using (auth.uid() = user_id);
|
|
```
|
|
|
|
It would translate to this whenever a user tries to select from the todos table:
|
|
|
|
```sql
|
|
select *
|
|
from todos
|
|
where auth.uid() = todos.user_id; -- Policy is implicitly added.
|
|
```
|
|
|
|
## How it works
|
|
|
|
1. A user signs up. Supabase creates a new user in the `auth.users` table.
|
|
2. Supabase returns a new JWT, which contains the user's `UUID`.
|
|
3. Every request to your database also sends the JWT.
|
|
4. Postgres inspects the JWT to determine the user making the request.
|
|
5. The user's UID can be used in Policies to restrict access to rows.
|
|
|
|
Supabase provides a special function in Postgres, `auth.uid()`, which extracts the user's UID from the JWT. This is especially useful when creating Policies.
|
|
|
|
## Tips
|
|
|
|
### Check authentication settings on Supabase
|
|
|
|
Navigate to Authentication > Settings on [app.supabase.io](https://app.supabase.io), and you'll be able to change settings for things like:
|
|
|
|
- SITE URL, which is used for determining where to redirect users after they confirm their email addresses or attempt to use a magic link to log in.
|
|
- Disabling email confirmations
|
|
- Enabling external OAuth providers, such as Google and GitHub
|
|
|
|
### Never use a service key on the client.
|
|
|
|
Supabase provides special "Service" keys, which can be used to bypass all Row Level Security.
|
|
These should never be used in the browser or exposed to customers, but they are useful for administrative tasks.
|
|
|
|
### Create a `public.users` table.
|
|
|
|
Even though Supabase provides an `auth.users` table, it is helpful to also create a users table in the `public` schema, which uses the same UID Primary Key as the `auth.users`.
|
|
For security purposes, the `auth` schema is not exposed on the auto-generated API. Created a `public.users` table allows you to interact via the Supabase client -
|
|
especially useful for cross-table queries.
|
|
|
|
Pro tip: if you want to add a row to your `public.users` table every time a user signs up, you can use triggers. For example:
|
|
|
|
```sql
|
|
-- inserts a row into public.users
|
|
create function public.handle_new_user()
|
|
returns trigger as $$
|
|
begin
|
|
insert into public.users (id)
|
|
values (new.id);
|
|
return new;
|
|
end;
|
|
$$ language plpgsql security definer;
|
|
|
|
-- trigger the function every time a user is created
|
|
create trigger on_auth_user_created
|
|
after insert on auth.users
|
|
for each row execute procedure public.handle_new_user();
|
|
```
|
|
|
|
### Disable realtime for private tables
|
|
|
|
Our realtime server doesn't provide per-user security. Until we build a more robust auth system for websockets,
|
|
you disable realtime functionality for any private tables. To do this, you can manage the underlying Postgres replication publication:
|
|
|
|
```sql
|
|
/**
|
|
* REALTIME SUBSCRIPTIONS
|
|
* Only allow realtime listening on public tables.
|
|
*/
|
|
|
|
begin;
|
|
-- remove the realtime publication
|
|
drop publication if exists supabase_realtime;
|
|
|
|
-- re-create the publication but don't enable it for any tables
|
|
create publication supabase_realtime;
|
|
commit;
|
|
|
|
-- add a table to the publication
|
|
alter publication supabase_realtime add table products;
|
|
|
|
-- add other tables to the publication
|
|
alter publication supabase_realtime add table posts;
|
|
```
|
|
|
|
We are aiming to deliver enhanced realtime security by Q1 2021.
|
|
|
|
## Next steps
|
|
|
|
- Read more about [Row Level Security](https://www.postgresql.org/docs/current/ddl-rowsecurity.html)
|
|
- Sign in: [app.supabase.io](https://app.supabase.io)
|